You are right. And it'd be absolutely irresponsible to expect _everybody_ to drop things on the floor and adopt a new protocol (implementation) over night.
However, it'd be equally irresponsible to ask for an innovation budget of 0 percent. The reason one bothers with new approaches is, of course, that fixing things on a conceptual level prevents many of the debugging sessions that you had to go through with the old approach. Why QUIC if there is TCP/TLS/HTTP?
IPv4 and NAT are literally _everywhere_. It's tested and well-understood (one would think). But—and that's just my opinion—I sure hope that, one day, we will not have to deal with that mess no more ...
Uhm, I have grown up with Macintoshs and I still use them. So, my comment has at least double the emotional intensity compared to the author's. ;-) In all seriousness, I say this because it is clear that his post is mostly based on an emotional attachment to a tool, not on critical thinking.
Maybe I misunderstood, but if I understood him correctly, the premise is that Hypercard would still be around if it did not collide with Steve's vision of a world of dumb users and smart engineers. This is wrong on so many levels, I don't even know where to start. Are you willing to learn?
First, Hypercard was created when 13" 256-color displays were state of the art (actually even earlier) and there were exactly two devices to interact with your Macintosh: a keyboard and a mouse. So, for simple tasks, it was quite easy to create a tool that would allow you to stick together a simple program using clicks and a verbose scripting language. Nowadays, however, general purpose applications are supposed to work on a variety of devices, from 4" phones with touchscreens to desktop-Macs supporting 27"+ screens being used with traditional keyboards and mice. Maybe this will change in the future, but if you want to precisely describe a structure (GUI-compontents) in a generalized fashion, a textual representation (e.g. react-components), so far, is just superior to any GUI-tool that is around.
When hypercard was created, VCS (such as git, svn, etc.) weren't really a thing. Most software was developed in about the same way as you created Hypercard projects: You made changes to your main copy and that's that. Today, you don't even think about starting a software project without having vcs in place. Similarly, when Hypercard was created, many software methodologies weren't a thing: Unit Testing, Integration testing, etc.
Now, I am a software engineer, and while I never wrote Hypercard applications myself, I once found myself maintaining an Filemaker-Application. Filemaker, I reckon, is very similar to Hypercard in that you plug together your app using a GUI and some overly verbose, pseudo-simple scripting language. And, needless to say, this was an absolute disaster: In the beginning, it was a simple tool that automated a couple of tasks and it was created in a very short period of time, thanks to the easy-of-use of Filemaker. However, as with all other tools, it grew in complexity. Now, ever tried to track changes in the source code using Filemaker-files? Ever tried to unit test Filemaker-code?
And don't get me started with the absolute ludicrous idea to use programming languages that resemble a natural language. Claiming that this is as effective as using an abstract language is akin to describing complex mathematical facts using only a natural language—while possible, it is completely unfeasible.
However, it'd be equally irresponsible to ask for an innovation budget of 0 percent. The reason one bothers with new approaches is, of course, that fixing things on a conceptual level prevents many of the debugging sessions that you had to go through with the old approach. Why QUIC if there is TCP/TLS/HTTP?
IPv4 and NAT are literally _everywhere_. It's tested and well-understood (one would think). But—and that's just my opinion—I sure hope that, one day, we will not have to deal with that mess no more ...