My big problem with web application (in a true application sense - not things that are just hypertext and shouldn't be applications at all!) development is that the DOM+CSS model is not made for rich UI experiences. Basic paradigms from desktop applications like spreadsheet cell selection, draggable cards (think Vizio/UML), modals, and MDI / multi-document interfaces are non-standard and brutally challenging to construct in a reasonable way using the DOM.
What I'd invent would pretty much be Silverlight without the Microsoft, honestly - a typed UI framework built on a widget and widget-binding model which would allow a smooth mixture between OS-level widgets (and the accessibility affordances they provide) and hand-controlled rendering/drawing, with a stripped-down runtime enabling resource constrained clients to execute client-side code which would hide / paper over the resource constrained backend connection.
Anyway, I also think this is orthogonal to the argument in this thread, because I think that most of the conversation and the sentiment of the original tweet is to call out applications that SHOULD be hypertext, not applications. For applications that need to be applications, I think things have gotten better, not worse, although they're still pretty bad.
My understanding from working at Opera at the time (2004 and onwards) is that the "senior" (experienced) people were busy implementing stuff in the browser engines and various GUI platforms. We hired very young (often like 17-18) and very smart people who had experience actually writing HTML/CSS/JS to work on developing web standards. They naturally typically had very little commercial software development experience.
After a while it kinda became a competition - which browser company's web standards people would be leading in terms of ideas/innovations. How many web APIs could browser company A do, vs browser company B. That's when the complexity really started accelerating. Then Safari and Chrome happened.
I wish we had spent more time working with these web standards people (we had so much experience building GUIs, for instance). They were really friendly and approachable, but we were all so busy with actually building the browsers, during these browser war times. It feels like a missed opportunity, in retrospect.
But nevertheless I think Java/JAWS got basic stuff still right: run applications directly from network (with auto-updates), have security controlled sandbox, be fully cross-platform and portable, and have useful stuff built-in, and even had the PWA-like thing that you could have desktop shortcuts to JAWS applications.
Regarding startup time, I do wonder what would be the startup time of your typical Electron app on a late 90s-early 00s PC hardware. Somehow I'm imaging JVM might not be that bad in comparison...
I would have liked to see a web built on Java tech.
The main downside, they only work on Windows, MS once had Silverlight for Mac but it wasn't particularly good.
It used to be possible (and done) to have a thin client X server that would have the whole desktop running elsewhere. You could run a computer lab with a bunch of thin clients and a handful of desktop servers for lack of a better word. That was probably hundreds, maybe thousands.
Since then, though, X moved a lot more work from the Xserver to the clients; text is almost exclusively rendered on the client and passed as an image to the server to display.
If you did a classical experience, it might work ok to millions, but the user experience would have to be pretty meager. There's also the issue that there's not really a good way to sandbox different X clients; so nobody in their right mind would let a random internet server connect to their Xserver. Connectivity issues abound as well.