Immature technology
The technology you want to bet on is the right shape but is not yet mature, and someone has to decide.
Where it goes wrong
The cost of a technical decision lands on whoever implements and maintains it, and that is usually not the person making it. Judged on technical merit alone the decision looks right, and the bill goes to someone who had no say in it.
That is what makes 'we can make it work' the wrong test. I have won that argument, shipped the thing, and still been wrong, because beating a tool into doing what you want does not make it something your team can own.
How I'd handle it
Before options get compared I get the ownership question answered out loud. Who maintains this once it ships, and is that person in the room while the choice is being made? A team that will have to run something fragile has a real engineering objection, and it outranks a benchmark.
Only then do I compare the options against what that team can carry today. The right decision is the one the team can live with.
Where I've done this
I bet on Rust at Redis before its async support was finished. The first place that bet landed in the cluster software was a component not allowed to fail: I ran on nightly builds with the libraries moving under me, and the language only stabilised what I needed after I had already committed. The component held. That is the same instinct that was wrong at Sunbit, and telling the two apart is the actual skill.
Kafka Streams was immature and I made it do what we needed anyway. Then one engineer on the team that would have had to run it said, in effect, that they could not support what they could not understand. That objection was better engineering than my proof was, and I had aimed my effort at the wrong target.
Recognize this on your team?
Let's talk