Other answers and comments focus on whether the team is likely give an accurate estimate. We should also question whether the business understands the real benefit that they may get from a feature that isn't broken down or actually designed.
It would seem better that the business should already have a backlog prioritised by highest value and should be going after things in highest value order. In which case a more indepth conversation about how each of the features at the top of the list can be delivered makes most sense.
Another thing that may be ineffective about the discribed approach is sequencing of work. If the business grooms a priorised backlog of features, and the team breaks the top ones down into enough manageable work to draw from, then the team can pull work in an order that maximum efficiency and minimizes delivery risk.
What is typical is that business don't actially do the hard work of getting agreement on what the vision is, and what the priorities are, and understand that experiment and real user feedback might be more valuable than a ”guestimate cost” matched to a ”guestimate value”.
I can imagine people who advocate the approach saying ”well, we need to know approximately whether its small or massive before we decide to do it, so this up front estimation is important”. That is an example of de-optimising the whole process to deal with outliners of ”sometimes we ask for something only because we think it's quick and easy and it isn't". Well there are other ways of dealing with that then the described approach.
if we take that thinking to the logical conclusion you could get a situation with a team sitting around with low utilisation as features "didn't seem worth the effort". Yet surely it's better to keep the team at full utilisation and review the teams size and actual delivered value quarterly.
That beings us around to the true problem here. The business is using a feature by feature waterfall model. Up front cost benefit analysis is simply a flawed at any granularity in software development. What they should be doing is seeing the team as something they should be partnering with to maximise value delivery by keeping that team working optimally on the most urgent things.