Terminals are not enough (sysadmin version)
Have you thought about the usecase of Chromebooks not as a fully independent machine, but something more akin to a thin-client remote access device? [...]
(The difference between thin clients and Chromebooks is important, but I'll get to that later.)
Let us call such devices 'terminals', because that is what they are. In the old days terminals worked over serial lines (and still might support windows); in the modern day the Chromebook has a browser and a SSH client to handle your remote access needs.
Using terminals sounds attractive for many system administrators (and some developers); after all, we work on servers anyways, often off in some distant datacenter or cloud provider. Periodically someone gives it a good try and for some people it can even work reasonably well. However, my view is that terminals are not enough in the long run because the interface they give you is limited and narrow and cannot match the richness possible with genuine local computing.
(I'll assume that we don't care about working when you have no network connection or the servers are unavailable. If this is an issue then a terminal is not an option in the first place.)
In the concrete, the interface you can deliver through a web browser
doesn't match what you can do with a native client with full GUI
access. Part of this is because of necessary browser limitations, but part of this is because the browser
must work through a web server on the remote end; it can't easily
sit directly interacting with the system and the rest of the things
you're doing in the way that a graphical program working side by
side with the rest of your session can. 'Emacs in a browser' is
perhaps theoretically possible but is clearly much more awkward
under the hood than '
emacs file'. The same is even more true of
what you can do through a text terminal instead of a GUI.
(Remote desktop software doesn't solve this; instead it essentially turns your terminal into a display. What you really want is remote windows and even that is crucially dependent on a fast, low-latency network and a capable display and event protocol.)
More generally, a terminal is always going to make shared context harder and more awkward to create simply because that context is at the other end of things. Even with your terminal having multiple windows, you need a new login session or a new browser window or the like, and they have to be set up and established. I have an entire elaborate environment designed to make this really easy and it is still not as fluid as it is for local things (cf).
You can get a lot done through a terminal. It's not terrible. Much of the time you may not really notice what you're missing. But you are missing things, and every so often you'll run into the limits of what you can readily do by reaching through the narrow, constrained interface to the remote end that the terminal inevitably imposes on you simply by virtue of having a 'remote end'.
(This entry is purely from a work perspective for sysadmin work. For my personal use I have an additional separate set of views.)
PS: In the past I might have argued that terminals are also less customizable than true local computing. However, most people's local computing is getting less and less customizable all the time, so I no longer feel that this is a clearly winning argument in general. Something like my highly customized desktop environment and its special tools is clearly a far outlier today.
Sidebar: Thin clients versus terminals
The difference is simple: thin clients are really remote displays, not terminals. If the protocol is powerful and the connection fast enough, it's basically like being directly connected to the server. The obvious drawback is that it takes that powerful protocol and fast connection (and much more server resources). The less obvious drawback is that it's not at all obvious how to multiplex things so that you can sensibly connect to multiple servers at once.
Modern terminals like Chromebooks solve the multiplexing issue by being 'remote windows' instead of remote displays; each window or browser tab is a separate context and can be going to a different place. In Chromebooks et al, one of the drawbacks is that each browser 'remote window' is significantly less powerful than a full GUI program could be. This isn't a completely intrinsic drawback, as remote X over ssh sort of demonstrates.
(I believe that you can have a spirited discussion over whether any remote windowing protocol, X or otherwise, is up to the sophisticated demands of modern compositing OpenGL/3D interfaces with audio and synchronized double buffering and so on, or whether such remote protocols are intrinsically too slow and incapable of equaling local GUIs even for straightforward programs. I don't know enough about the state of the art to have an opinion.)