Do you have more examples of companies that are not feature factories? It seems the entire industry has adopted this pattern.
Actually, none of them are. They're just managed as if they were.
In a factory, you can literally have a machine that stamps out 1000 widget blanks an hour and if the operator does an hour of overtime, that's an extra 1000 widgets produced that day.
You've got your workers on 8-hour shifts and sales signs a contract to deliver 8,500 widgets per day? Then you know right away you're going to need 10-hour shifts, or regular overtime, or a second 8-hour shift, or a second machine, and you can figure out how much each of those would cost, and whether you've got enough car parking for the extra workers.
Whereas in software, your feature factory produces ???? per hour, sales promises customers ???? and an hour of overtime achieves ???.
Changing the topic from software development to R&D: the granular task oriented view is generally not good for greenfield research endeavours. It's a form of premature optimization. You're calcifying the search space and reducing flexibility to pivot immediately based on expert intuition and hunches. That being said, a coarse task orientation is necessary to keep people vaguely pointed in the right direction. The best resolution (time horizon) for task orientation depends on what you're doing.
Too bad that's pretty much the only such example that has been touted since... The 1960s, is it? And that it was, IIRC, recently either shut down or announced to be shut down sometime soon.
Thus, using this as an example seems, if anything, to illustrate not that "there are too!" but "there are dwindingly few".
When it comes to less intrinsically motivated team members, I don't have useful advice. Maybe they can contribute to research output, but that would require more traditional management styles which I can't comment on.
When it comes to satisfying constraints imposed by other parts of the org, I can't usefully comment on this either.
I guess the essential problem I'm trying to solve is how to respond when the MD or a product owner comes to me and says "The client wants our core algorithms to be adapted in XYZ novel ways. When can you deliver this?".