The post ultimately seems to boil down to "be more empathetic and considerate of your users", and building reliable software is of course one of the ways to accomplish that.

Unfortunately, the OP's points stem from various biases, and the idealism is harder to accomplish in practice than the OP makes it out to be.

> Almost all software that users encounter in $CURRENTYEAR is straight-up broken, and often badly.

Always been the case, whether now or decades ago. Many issues have been resolved; however, new ones will inevitably continue to appear. This is because the complexity of software will always increase, primarily as a result of market demands.

> My web browser has been perfectly competent at submitting HTML forms for the past 28 years, but for some stupid reason some ~~asshole~~ developer decided to reimplement all of the form semantics in JavaScript

Repeatedly unprofessional tone aside, HTML forms in their simplest form come still come with their own limitations and quirks.

Case in point, I've recently had to build a rudimentary form for uploading multiple files. By default, a file input field requires the user to select their desired files in one go, either by using Ctrl/Command or by selecting the files.

But, how do you allow users to drag and drop files from their file manager into the form? How do you allow users to select some files in one folder, then other files in another folder? What about an even simpler scenario: how do you let the user click on the "Browse..." button to select files, without overriding the previous selection? JavaScript is the answer to this.

Luckily, this specific problem doesn't require drastic solutions, though it hopefully does bring light to the fact that HTML forms aren't as perfect as they could be.

> Finally, stop letting economics decide everything you do. Yes, developers have finite time, and that time costs. Yes, users with annoying needs like accessibility and internationalization are more expensive to support than the returns they produce. You need to pay for it anyway. It’s the right thing to do. We can be profitable and empathetic.

Although I agree with the principle, the practical circumstances make it difficult to make this a reality. Many developers aren't full-time OSS developers like the OP is; instead, they work under an employer with demands, deadlines and restrictions in place.

This includes having to implement aggravating things like ads and abysmally re-invented forms, or having to sacrifice empathetic features for profitable features. In an ideal world, this shouldn't even be a problem, or at the very least a developer should speak up or change jobs when users' rights are compromised. Unfortunately, locations and opportunities can make this difficult, never mind having to keep the family fed.

There are of course many scenarios where it's the developers making incompetent decisions and being architect astronauts. But the problems the OP mentions are not caused by that; like they said, they are caused by economics. Economics shouldn't be the dictator of technical decisions, but unfortunately for most developers, it is.

This is why I believe that most of the user-hostility & brittle complexity is a result of a deeper problem, which is the developers not having enough liberty and resources. I'm confident that most developers didn't implement user-hostile features - including intrusive ads and awful forms - because they wanted to. It's easy to blame the developer for building the things, but in most practical cases, they built based on what they've been requested, not on what they've decided. I'm sure a developer will dedicate much more time and resources into robustness and friendliness if they were given the opportunity to.

Luckily, I have full control over all the technical decisions on the software I build for my employer, so I do strive for simplicity and robustness as much as I can, but I'm all too aware that not every developer has that luxury. I hope the OP will realise this, too. This isn't to spare developers from responsibility and accountability, but to bring to light that the problem the OP poses is much more nuanced, both in its causes and in its details.