I think the article conveys a fairly narrow understanding of why Apple would want to move slowly with some features in Safari on iOS. It's a bit reminiscent of complaints about iOS Safari not supporting Flash and Java, and Apple's reasons are likely similar: partly for business reasons, but also for reasons of user experience, security/privacy, and battery life.

As an example, I like game controllers and vastly prefer them to touchscreen interfaces for most games. But Apple specifically delayed game controller support in iOS (and in Safari) to encourage developers to make games that used touchscreen controls and worked out of the box without an external game controller. The rationale was: it's a better user experience to not have to use an external game controller, and it's clunky to have to carry a controller around with your phone.

As another example, multithreaded/parallel webasm is a great feature for developers, and it could also burn a lot of power and degrade the overall performance of the system. A rationale for delaying it could be: battery life and overall system performance are more important than performance of a single web app.

At the end of the day, Apple is certainly trying to make even more money, but they are also trying to figure out what the overall best user experience will be across their entire user base. This is not the same as the best developer experience, and sometimes they are in opposition.

Developers, for their part, can vote with their feet. If they truly believe web technology is the best way to deliver apps, then they can develop for Chrome, Electron, and platforms that support the latest bleeding-edge web tech, and ignore Safari.