Somewhere along the way, tooling turned into identity. People do not say they use a framework, they say they are a person who uses it. And once a tool becomes part of who you are, you defend it the way you defend a team you support, which is to say not with reasons.
I try to stay out of that. Not because I do not have preferences, I have plenty, but because the preference is supposed to be the output of thinking, not a substitute for it. When I pick a tool for a job, I am usually running through the same handful of questions, and none of them are which one is best.
What is the actual shape of the problem
Most tool arguments happen with no problem attached. Someone asks which database is better, as if that has an answer. The honest response is always a question back. What are you storing, how does it get read, how much of it is there, how wrong can a read be before someone gets hurt. A tool is only good relative to a shape. Get the shape wrong and the best tool in the world will fight you every day.
So the first thing I do is refuse to choose until I can describe the problem without naming any tool. If I cannot, I do not understand it yet, and choosing now just locks in my confusion.
What does this cost me a year from now
New tools are exciting on day one and expensive on day two hundred. The question I have learned to ask is not how fast can I move now, it is how fast can the next person move, and how fast can I move once the honeymoon is over. That means looking at boring things. How good are the error messages when it breaks at 2am. How many people know this well enough that I can hire them. How long has it been around, and does the team behind it have a reason to keep it alive.
A slightly less shiny tool with a decade of answered questions behind it will usually beat a newer one that is technically nicer. The nicer one makes the demo better. The older one makes the Tuesday afternoon better, and there are a lot more Tuesdays than demos.
Which decisions can I undo
Not all choices carry the same weight, and treating them like they do is a quiet way to waste a lot of time. Picking a component library is cheap to change later. Picking how your data is modeled, or how services talk to each other, is not. I spend my care in proportion to how hard something is to reverse. For the reversible stuff, I pick something reasonable and move on, because the cost of deliberating is higher than the cost of being slightly wrong.
The trick is being honest about which bucket a decision is in, because a lot of things that feel permanent are not, and a few things that feel casual absolutely are.
Where the religion actually hurts
The cost of being loyal to a stack is not that you use a slightly worse tool. It is that you stop seeing the problem clearly. If you already know the answer is your favorite framework, you will bend the problem until it fits, and you will not even notice you are doing it. Staying agnostic is mostly a way of keeping your own eyes open.
None of this means I have no opinions. I reach for the same handful of tools most of the time, because they have earned it across many projects. But that is a default, not a rule, and the moment a job pushes back on the default I want to be able to hear it. The goal was never to use the right tool. The goal is to understand the problem well enough that the right tool becomes obvious, and then to have no ego about picking it.