Despite Chrome being speedily updated when known security problems are discovered, the attack surface compared to a dedicated client is huge: the 2-decade-old /usr/bin/ssh + /usr/bin/xterm combo has no concept of a DOM, does not share computing interfaces available to untrusted users (e.g. shared web workers), cannot receive messages from untrusted frames (postMessage()), cannot even be addressed by untrusted content (chrome://path/to/trusted/script), does not almost transparently expose ring0 drivers (OpenGL), does not have thousands of LOC on subsystems with little battle testing (WebRTC) and so on.
Of course these features are thought to be secure, until they are discovered in the midst of a Stuxnet type scenario and suddenly everyone is patching like crazy. Wasn't Java considered invulnerable only 2 weeks ago? Look at what changed - somebody noticed it wasn't long after tens of thousands of infections already occurred, and today it is on every browser's plug-in blacklist. I can't recall the last I read about xterm in the Pwn2Own contest, or any 0-day in the past decade, nor can Google accidentally DoS my xterm because their sync service is down (happened last month).
Following from the truism that the fastest, most bug-free code is code that doesn't exist, the easiest way to reduce exposure to unknown attacks is to minimize the amount of code running. Security design 101. Using something with the complexity of a web browser to render an 80x25 vector used to administer potentially hundreds of thousands of machines is almost the antithesis of good protocol.