However, what worries me is that such framework...hides a lot for the
developers who use this framework but not actively develop it.
That's a good thing! It's one of the big reasons that such a framework helps you develop better, faster, and cheaper.
do not learn the itty gritties of the framework behind it
Sure, but that means that those same developers get to spend more time making their applications work better. Instead of having to know the entire soup-to-nuts set of systems that the company uses, they can focus on just part of that problem. They get to work with their users to build applications that really make the company perform better instead of wrestling with making disparate databases work together seamlessly.
And it works in the other direction, too. The people who build the framework don't have to know anything about the applications that use the framework. They get to spend a lot of time making the framework work better. Also, if they decide to replace one (or all!) of the systems to which the framework provides access, they can do it without breaking any of the applications that use the framework.
cannot transfer this knowledge to other companies
Surely, from the company's point of view, this is nothing but good.
which might cause devs who have become less motivated to stay anyway
Is this really a problem? Are you experiencing an exodus of developers who are unhappy that they don't get to write user interfaces and do low-level systems integration in the same month?
Case Study: Amazon
I think it's pretty well known that at Amazon, they use web services for everything. They have a zillion different groups which all do different jobs: determining the prices for all their stuff, updating product information, producing product pages, producing the page you see, ordering stuff, accepting payment, shipping stuff, figuring out what things you might want to buy, and so on. It's probably safe to say that nobody in the entire company really understands exactly what every one of those groups does or how they do it. All those different groups share what they do with each other via web services. Want to know what something costs? There's a service for that. Want to submit an order to the fulfillment group for picking, packing, and shipping? There's surely a service for that. And so on.
Now, this collection of web services might not qualify as a "framework" in the same sense that we often use the term (that is, like a collection of shared libraries), but it certainly fills the same role as the corporate framework that this question addresses. Both the corporate framework and Amazon's collection of internal web services provide an abstraction, a way to use a service without having to know all about how it works internally. Clearly, such an abstraction has huge benefits, and I think it'd be hard to make the case that the existence of such a thing would by itself cause good developers to leave.