Look - as I said in my other comment, the issue isn't that it uses a tonne of memory. The stock browser does so too. The issue is that it is using that memory in such a way that it is evicted too late. The app is multi-process, but they're putting background services in the wrong process - they run in the main process that you'd expect to be heavy on memory usage. So instead of the memory-heavy UI stuff being evicted shortly after the UI goes away, it is evicted after all other background (multitasking) processes - including the launcher - have also gone away.

Note that my screenshot shows the active (i.e., not background processes that can be thrown away at any time) section of the running processes screen.

I should have qualified my statement by mentioning that the Chrome app process runs a couple of background services - this causes it to be killed for low memory after normal background processes (the actual behaviour is a little more complex than that, but that's the gist of it), which could potentially impact the performance of multitasking. The proper thing to do is to run background services in a separate process from the UI or whatever uses the most memory so that the latter can be evicted more quickly.

I stand by my assertion that optimising for memory isn't a priority at Google. An Android engineer poignantly put it (sorry, can't remember who) when they bragged on G+ that Android 4.0.3 was the first time since Gingerbread that they'd run the OS on a <1G RAM device (namely Nexus S). Then again, as an actual embedded engineer (none of this gigs of RAM crap!), all I care about is memory usage...