Dimitri,
That statement is great in a perfect world, but there is no way of knowing when a page in a working set might spill over in to the paging file without some hard testing. Exchange does a good job of keeping pages in its own working set, but there are always variables out there that might cause a page to go to the standby list and then eventually be paged out of memory.
To play it safe, the recommendations that we currently provide is to protect from worst case scenarios, otherwise, if something went wrong, the store would become unstable and possibly crash which is what we don't want. If we can protect our working set backed by a paging file, we could at least recover, albeit not quickly on a slow drive, but in due time the Store process would eventually start responding.
In certain instances, it is very hard to maintain balance as other 3rd party applications can behave badly on a server and consume it's fair share of memory/handles causing undesired results.
Most of the problems that I have come across is due to some other application consuming memory causing Exchange to not behave the way you want. It is a perception thing as Exchange is unfortunately the victim of something else going wrong on your server.