Bitcoin "accounts" feature - Is it practical or scalable? On the bitcoin wiki's "Accounts explained" page:
https://en.bitcoin.it/wiki/Accounts_explained#Account_Weaknesses

It clearly states:


  The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.


So my question is that should the standard web developer creating a bitcoin web app using the RPC interface use (or ever use) accounts? 

Should we always use the default "" account since we technically always have to use accounts when accessing the RPC for things like getting the entire servers balance?

Should we just handle our users accounts on our own databases and ONLY use bitcoind for things like listsinceblock() to store transactions and user balances in our databases?
As mentioned in the page you linked, it is a bit awkward to use Bitcoin-qt's accounts system. Don't bother with accounts as they are intended to be a way to manage your money within the program. When you're having thousands of accounts you are already doing it wrong.

So how do you structure a service to do this?

Handle accounts completely on your database. When you generate an address, store it as a field under a user in whatever database table/collection you have for users. This will allow you to quickly and easily scale your address counts in the event you grow large, Bitcoind does not scale well.

Handling receives

This is awkward to do with the current state of Bitcoind, the program never really intended to support large services. Bitcoind can efficiently detect receives to addresses in wallet. When you use the RPC interface and use the "getnewaddress" command, Bitcoind will store it in it's wallet. I've tested out Bitcoind with a million addresses before, it takes a solid half hour to start up but receives are snappy with no noticeable slowness. 

Use walletnotify and/or blocknotify to get new transactions and blocks. Those two are arguments you can put in the bitcoin.conf file that specify a program to run when one transaction or block happens. Walletnotify is called per new transaction to or from an address in wallet.dat and gives a notification when it receives the transaction (unconfirmed) and then again when it's in a block (1 confirm). Blocknotify works per block. See the suggestions on how to use walletnotify here.

Just load the hashes walletnotify gives you in a database and then on block check if each one has enough confirmations, be thoughtful of the fact that Bitcoind usually has 2 walletnotify events per txn (one for unconfirmed and one for when a txn makes it into a block). And make sure the program you call is light weight and quick.

The pro method

This ways a bit advanced, rarely used and you will need some C++/Java/Python/Go proficiency. The community have made many Bitcoin implementations available as open-source libraries you can link to. Many larger services simply need more complexity with receiving transaction and better scalability, which Bitcoind struggles to provide.

It's a lot more work but you can make your own "node" with features you need easily with the libraries available for a wide range of languages. For Java there's BitcoinJ, widely depended on and reliable. For C++ there is Libbitcoin, which has pretty good examples and looks simple. Python has a bunch of node implementations and modules. Even Golang has something pretty popular. 

If you need examples, Github has a lot you can find on search.