Having been a developer, contract developer, consulting analyst, and consulting architect, I can say you are right. There are challenges for business analysts, similar to this.
But it's not the same league. Technology often comes down to "it can be done" or "it can't be done without a lot more effort than you are willing to pay for".
Sure, a business analyst may have similar problems ("this process works" vs. "this process would take 5 people a week, each time - but we only have 1 person for 4 days"). However you, the business analyst, are not usually then expected to go away and actually make X happen - you hand over your requirements to other people for them to "make it happen".
So you think BA's can not learn, even through experience, what can or can not be done?
Sure, there's always somebody else, same role or not, who has more expertise, but don't confuse role/title for expertise. I've seen BA's with a decade of experience school junior engineers on what can or can not be done.
It's that when it comes down to actually making it work, it's the engineer that has to provide a working solution to the specification. Not a figurative engineer with years of experience and knowledge. The actual person that has the task. Pretty much everyone else in the chain has to make assumptions about what is possible, in what time frame, with what resources. Yes, the more experience you have, the better you get at doing that.
But trust me when I say that all too often, even product engineers for million dollar figure products, have little idea if X is possibly in time Y until they actually try and do it. (I've worked at multiple companies with multi-million product licenses, and seen it at all of them). Sure, a few of the delivery engineers had a much better idea. But there was no way any of the analysts, project managers, and especially not the sales engineers, had any clue about the time. You'd get answers from 1/10th Y through to 10 x Y - 10000% variance.
But it's not the same league. Technology often comes down to "it can be done" or "it can't be done without a lot more effort than you are willing to pay for".
Sure, a business analyst may have similar problems ("this process works" vs. "this process would take 5 people a week, each time - but we only have 1 person for 4 days"). However you, the business analyst, are not usually then expected to go away and actually make X happen - you hand over your requirements to other people for them to "make it happen".