Should tool selection be treated as a strategic decision instead of a team preference?

I would not treat tool selection as inherently strategic, but neither would I leave it entirely to team preference.
The governance level should depend on the consequences of the choice.

If a tool remains genuinely local, is easy to replace and creates little dependency outside the team, local autonomy may be entirely appropriate.
But when it begins to shape shared data, reporting, integrations, security, workflows, governance or vendor dependency, the decision becomes increasingly organizational.

My selection process would therefore start with the problem and operating requirements, not the products: what work and decisions the tool must support, which data and interfaces it will affect, what constraints must be respected, how much local flexibility is needed, and how difficult the choice will be to reverse. I would then evaluate functionality, interoperability, lifecycle cost, security, governance implications and exit options.

I would also be cautious about treating fragmentation as inherently inefficient.
Multiple tools can preserve specialization and local fit, while standardization can itself create workarounds and rigidity.
The relevant question is whether the overall tool landscape remains coherent and its interfaces manageable.

So I would favor local choice within proportionate organizational guardrails.
The more a tool creates cross-team consequences, lock-in or difficult-to-reverse dependencies, the stronger the case for treating its selection as an architectural or strategic decision rather than simply a team preference.