The formatting actively prevented me from processing more than half the article's content but I agree with the premise as far as I was able to get it: if you're a EU-based company or individual it's a good idea to move away from US cloud services unless you're a subsidiary/employee of a US company.
The legal concern for EU businesses should be self-evident given that EU-US data sharing provisions have been struck down again and again with every replacement inheriting the exact same issues of the one before it. There simply is no way for US-based companies to comply with EU data protection laws while still complying with US laws granting law enforcement and federal agencies warrantless surveillance powers - they'd actively have to break US laws to comply with the EU laws.
That said, this is much more difficult for some things than others.
If you're building on AWS, there's simply no drop-in replacement. Yes, there are EU equivalents in the same category but it's very different from "simply" switching between AWS, GCP and Azure.
For package registries like NPM, moving away also means abandoning the standard ecosystem. For private packages this may be an option but for public packages at some point you will likely need to involve a US service. GitHub is kinda in the same boat - although alternatives to GitHub exist functionally, GitHub is also a platform for discoverability and ease of access. These platforms act somewhat as monopolies for these purposes simply through the network effect of so many people using them.
Even Microsoft 365 (or Google Workspace) can be somewhat difficult to avoid given that so many things simply integrate easily with it compared to whatever company-wide "productivity suite" alternative you might want to use. That's without even getting into the quality and compatibility of the tools themselves.
What seems far easier and often overlooked are the infinite number of dime-a-dozen SaaS providers: emails, monitoring, realtime, messaging, payments, etc etc. These provide an easy first step for most companies and by adopting these incrementally you can also more easily wean yourself off bulk service offerings like AWS. Of course this comes with the cost of a diverse stack: you can't simply hire an AWS certified devops guy and expect him to know how every single service works, on the contrary none of your folks might know how a given new service they need to add works.
Another consideration that's becoming increasingly relevant is the (un-?)intentional vendor lock-in imposed by AI assistants: the LLM your devs or management is using might be able to generate a SOA app built on AWS or Azure but it will likely be less helpful integrating with a EU-based specialized service provider with a fraction of the userbase. Not to mention the AI assistant itself probably runs on US-owned infrastructure and is likely provided by a US-based company.