If I can't trust you to make a good choice on which technology to use why do I think I can trust you to make good choices in other aspects of your job. If you don't feel confident to make a technical choice then what you are telling me is you don't understand, and don't want to learn. Not really a desirable quality.
My expertise is in designing and building software, not in organizing teams for optimal productivity. The tools and tech that make the most sense for my project will get me to 100% optimization, but if I pay down a 5% optimization cost to bring all teams in my organization 80% to 90%, a manager should be the one making that choice, not me.
Pretending like everyone has the visibility into the org like you do will get you into trouble, and giving that visibility to everyone will harm their ability to focus on their jobs. I'm not a manager for a reason, I don't want to make those choices, but I need someone to.
Also, not everyone gets to work at Google. Advice like this needs to have value at Medium Sized Company, Inc., because those are the people who are most out in the cold. An Apple product manager has every tool on the planet available to him/her to figure out how best to help his/her team, but the guy/gal managing a dev shop in Carson City might not.
Empower your tech teams to do great work, it doesn't require you to be a google or apple, or podunk startup. I have seen empowered teams at 10 man contact shops and 100,000 fortune 100 companies. If you run into a company that tries to tell you something else run away, you will find politics and infighting alongside terrible technology and an inability to deliver
Doesn't this just encourage silos?
There are lots of reasons why you may never hit that state of everyone self selecting the same or a very similar stack, but they are never technical and they always indicate a team structure problem that is going to cost you way more if you don't deal with it then the amount of duplicated work you might encounter
The reasons that get hand waved away in this article are exactly the reasons you can't ignore consistency across teams. There is value in having just one library that multiple teams use to communicate via HTTP to various services, there is value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more.
I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because that is valuable. Letting the folks building the stuff decide which things to build first is much more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them).
Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.