What I have found out, there are some cultures that say "No" when in fact they mean that they won't be able to do it with current resources. Which is absolutely fine to disclose, but for some reason, they don't do it. They just say "no".
Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.
Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.
Aside from the MBA speak you have in there...you are obviously detached from the team in any meaningful manner. You might have had a technical background at some point, but you've lost it due to going down the PM/MBA path, and have forgotten how hard it is for developers to do any kind of estimates.
That is why you have senior developers and software architects that are in charge of the project as a whole and its general road map. You as the PM need to be working with those people - 1 or 2 people that will really know the product, its source, and customer base really well - to get the estimates, etc you need. They should in turn be training the lower devs to be able to do the same (though that almost never happens) while they collaborate to get the estimate figured out.
Then it is up to the PM to present and defend that cost to execs in a cost/value analysis and if numbers work out the PM can actually help the team get funded and get the job done. But if the team only says "no" instead of "yes, but ..." by providing a complete analysis for a means to make it a "yes" sometimes it just doesn't get to a "yes" and the whole product gets scrapped.
Wrong. The PM is but one part of the team in deciding on the estimate. Their job is to help identify what is valuable to go after and work with the team to build up an estimate and make the case. Their job is to run the financials for the team, ensure there's enough developers and resources, etc. Their job is to be the voice of the team to fight for the product in the organization, to ensure it get appropriately marketed and arrange for all the other non-technical stuff that goes into the product while working with the team to get the technical stuff completed.
Sadly, this is where the MBA/PM courses fail. They focus too much on looking at this in an unbiased manner based on balanced sheets; team work is against other CxO's, and the people that do the real work are turned into "resources" that can be "allocated" without any information or regard for what those "resources" really are. That's not to say that there is not a place for that kind of perspective (there is) but it's not how you should be looking at it the vast majority of the time.