You do not become a photographer by buying a lot of gear. You train your eye, study, and maybe buy gear eventually when you know why you need it.
You do not become a software developer buy buying a bunch of supercomputers. You study, you start with smallest things, and maybe you buy hardware eventually, or deploy a lot of cloud instances, when you know why you need it.
You do not become a successful company by quickly raising tons of capital. You study, learn about the markets and the needs of your prospective customers, start with building rather simple things, and maybe eventually you take hefty investments, when you know why you need it.
You can go on and on. The old adage is to use the right tool for the job. This begins with understanding the job, and understanding the need of tools. Then you can choose the tools. Starting with tools, especially expensive tools, and believing that the use of these tools will automatically help achieve success, is a mistake.
I don't think the point is, "no need for so much software tooling" but rather, "software tooling by itself isn't sufficient."
(And that "underlying hard-work, the focus on stuff that matters, and courage to make a decision" are much more significant.)
Specifically, reactionary conservatism about tools and services can be a competitive disadvantage.
In several workplaces I have seen this attitude co-mingle with pride in original code, and result in a counter-productive NIH (Not Invented Here)[0] attitude (reinventing wheels). Macho/heroism makes it worse.
While trend-following can be inefficient, if the engineers are both excited and humble and ready to weigh many trade-offs, this inefficiency might be "cheaper" than reinventing wheels for all problems.
Cue platitude: it takes balance :)
[0]: https://en.wikipedia.org/wiki/Not_invented_here
---------------------------------------------------------
EDIT:
To clarify I'm talking especially about _uninteresting problems,_ for which there may be an obvious off-the-shelf solution, such as when I've seen engineers invent a build system from scratch (and then cost _lots_ over years as that custom thing needs maintenance) ... when their needs could have been met by the language's standard tooling and using its plugin architecture.
Or, when "just use sticky notes and a whiteboard" gets so stubborn that a growing team stays in chaos for lack of organization.
On the other hand, it is quite bad when trend-following causes not just churn (switching tools), but overkill that introduces tons of cost and risk. i.e. distributed systems where you didn't need one. Relevant on this point: You Are Not Google by Ozan Onay https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb