Good question. If the wallet generates a new address every time an address is used for receiving funds, it means the more transactions a user has, the more addresses a wallet has, the more addresses a wallet has to watch for incoming and outgoing transactions.
For a web wallet that consumes a blockchain API provided by a server, how scalable it is depends very much on the API design. If the API is the blockchain.info style API, which indexes unspent transaction outputs(UTXO) and transactions by addresses, it is not scalable, because the number of requests the client needs to make to the server increases linearly with the number of addresses the wallet has.
One alternative is to also index transactions by extended public keys. An HD wallet with one account is then able to query the API with its account extended public key with a single API call regardless of the number of addresses the wallet has consumed. The heavy lifting of generating the chain of addresses, scanning the addresses for transactions is pushed upstream to the API server. The response can be streamed to the client as its size still depends on the number of addresses a wallet has consumed. While the client is still receiving responses from the server, it displays “Synchronization in progress” to the user. The API should also embed the latest block id in the response to the client, and allow client to query with a since parameter which can be any block id. The client can then store the transactions data and the block id from the last sync. And for the subsequent syncs, the client supplies the latest known block id as the since parameter together with its extended public key.
Note that unlike addresses, extended public keys cannot be extracted from transactions. Therefore the indexing is done on demand – the first time an extended public key is used for querying the API is when the server scans through its existing data and creates the necessary indexes.
One major drawback of this approach is that the server needs to be aware of the extended public keys of HD wallet accounts. That’s some information that clients have to trust the server with. In case the API server is compromised, leaking of extended public keys means lose of user privacy.