The main gain from doing this is that it reduces the amount of time either the mailer program or the client access program needs to enumerate the mailbox. Depending on what file-system the spool volumes are formatted with will change how it handles the 'lots of little files' problem. Some are good, some aren't.
Of course, what you use for a mailer is a big, big factor in how this impacts things. If the mailer uses MBOX format but no external indexes, it'll have to read the entire file to build the header-data needed by the clients, and will still be faster than 2000+ files as it only has to do one open/read/close cycle instead of 2000+ of them. If the mailer indexes header data, the format of the spool volume doesn't matter nearly as much since header-data will be stored separately.
Also, not all mailers are the same, even in Unix-land. The big mailers use database backed stores for mail instead of file-backed stores, or a hybrid system where the index data is in a database and the actual messages (or maybe just the bodies of the messages) are out in a file-system somewhere. These types of systems tend to scale nearly logarithmically (rapid performance loss as the system goes from zero to full, then performance loss approaches linear as growth continues, up until memory limits make database access thrash swap), so large message counts don't always mean really bad performance. A key concept here is that client-view folders are logical.
The reason you're not seeing this much is because most mailers either use DB backends or MBox because of the itty-bitty-file problem on a lot of filesystems.