Before microservices were a thing, I had the chance to work on a couple of telecom systems written in Erlang/OTP, but it wasn't until years later that I realized we were already doing most of the things people were using microservices for, with the single exception of being polyglot (although Elixir and Gleam are starting to challenge that).
Small teams were dealing with specific functionality, and they were largely autonomous as long as we agree upon the API, which was all done via Erlang's very elegant message passing system. Scalability was automatic, part of the runtime. We had system-wide visibility and anyone could test anything even on their own computers. We didn't have to practice defensive programming thanks to OTP, and any systemic failure was easier to detect and fix. Updates could be applied in hot, while the system was running, one of the nicest features of the BEAM, that microservices try to address.
All the complexity associated with microservices, or even Kubernetes and service meshes, are ultimately a way to achieve some sort of "polyglot BEAM". But I question if it's really worth it for all use cases. A lot of the "old" technology has kept evolving nicely, and I'd be perfectly fine using it to achieve the required business outcomes.
Looking back at the time this article was written, I used to believe the same things, that people would rise up, mesh networks were going to change the world, and the distributed web was going to change everything.
I ran IPFS nodes, I was on cjdns (Hyperborea network), I joined all alt sites trying to disrupt FB and whatnot (Diaspora, Friendica, Mastodon). I paid a lot more to my ISP to have no bandwidth caps (a key blocker for dweb technologies).
In the end, nobody came. Nobody else cared. The huge time sink that was necessary only to maintain these technologies was eating either on my work or my personal life. I wasn't even capable of convincing family members in 3 countries to use Signal or Wire instead of WhatsApp. So I gave up.
Every once in a while I take a peek into the dweb world, because I just love the technologies, but I see little to no movement. Outside folks like archive.org, few others have serious, production-quality systems based on dweb techs.
When I was a product lead, the most important question was "why". What problems are you trying to solve. And the problems need to be so clear, obvious and powerful that customers would be willing to pay to solve them.
As I see it now, even if the problems described in the article are real, the great majority of people don't care enough to make the effort required to change their habits.
Don't judge the author too harshly. Ingrid presents an overall perspective of the entire field. Yes, some definitions are somewhat skewed, but I'm sure many people see things the same way. In a way, the fact the author wrote the article and we're all reading all these comments, is because we all care about this and we want to see a truly distributed web succeed. So it's ok to try to reason how we get there.
In all honestly, I've had very similar thoughts. As someone who started with BITNET before the Internet, I always believed "the Net" was supposed to level the field, and we no longer have to be "consumers" but rather willing participants capable of innovation, on our own right. I know, how naive.
Where I disagree is in the solution. It's not political. Whenever you think about the Internet, you MUST think global. I've had the chance to visit around 35 countries, and I've seen first hand how governments don't work for people, for the most part.
It comes down to this: we (geeks and nerds) need to get out of our comfort zone and think in terms of user experience. We CAN create amazing things. But we must think about the people using these solutions. People use Dropbox because it's easy, not because it's good. Same for Gmail and other services. If we are not creating solutions that can be used by anyone, in an easy and straightforward fashion, we're not doing our job. If companies don't see value in what we are creating when it could help them tremendously (i.e. IPFS) then WE are doing something wrong.