Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility.
At the same time, reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision.
(I can totally see why the framework-de-jour option gets chosen so often though - because no matter how written-in-stone the original specs saying "There wil be no functinality required beyond showing/hiding divs and css animations between them" are, we've all seen projects where a last minute critical/showstopper requirement for the web page to include something insane like a fully functional email client gets dropped in the FE dev's lap the Friday afternoon before launch Monday. Sure, the FE dev made the choice to use React, and while some (perhaps a lot?) of that is "resume driven development", at least some of the blame is on bad sales people and project managers as well...)
Do people really do that? To me, that reflects bad frontend engineering practice. Even so for something like that, I'd use jQuery or something similar, because it's a much nicer API than the DOM.
I'm pretty sure gmail started out without a framework.
I'm pretty sure you're right.
I'm also pretty sure it's not only one of the big reasons frameworks exists as they do today (because it's perhaps one of the earliest and probably the most famous example of a web app that 100% _needs_ a framework for all the reasons discussed everywhere in this thread), but that it's also the poster child case of why every ambitious/opinionated/inexperienced FE dev builds their own framework (Of _course_ I can't use jQuery/Angular/React/Fluttr! _My_ ToDo list app is _groundbreaking and special_ - just like gmail was in 2004, I'll need to write my own framework for this. Stand back! <flexes>") ;-)
There is nothing preventing you to write nice and clean code in plain JS.