I've worked in both sorts of companies. The constant questioning may work well at smaller scale but kills productivity at larger scales. Putting aside that it inevitably becomes a political exercise as much as a technical one (because the different technical solutions almost always reflect competing priorities), it also requires perfect sharing of information across the organization, which does not scale.
Especially in any sales driven organization, I've seen it cause issues with infra teams questioning the need for certain features. Meanwhile, the answer is that the features are necessary because someone is willing to pay $$$ for them.
> Meanwhile, the answer is that the features are necessary because someone is willing to pay $$$ for them.
Just because someone is willing to pay for them doesn't mean they're worth doing. It could be that adding a feature makes other features harder to add or support. So sure, it might get you a win today, but it will cost you in the long run. And someone needs to be making sure the question being answered isn't "do we want a win today", it's "do we want the win today at the cost of a larger loss tomorrow" (when that's the case). And the sales team and higher managers don't see that. So it's the developer's job to make sure the questions are asked.
Sure, sometimes the answer is that yes, the feature is needed today, and it's worth the pain later caused by it. But if someone doesn't ask about the pain, it can't be considered into the decision.
I think the problem isn't constantly questioning! The major problem is many times, the ideas was top down, without a basic research or thought about possible RoI, wants to be discussed more because the team that will implement wants to know better and avoid mistakes, such behaviors always causes friction!
Especially in any sales driven organization, I've seen it cause issues with infra teams questioning the need for certain features. Meanwhile, the answer is that the features are necessary because someone is willing to pay $$$ for them.