IIRC, most of the problems with which I've had to deal were bordering on what once was called "large" but now would not be considered such.

Microprocessors and microcontrollers were devised as a substitute for large boards full of relatively simple logic elements capable of much greater speed but essential to get the job done no matter how fast. Microprocessors, when they were new, enabled the designer to do things one at a time, at moderate speed, rather than doing them concurrently with logic that was much more speed-capable than the task demanded. IIRC, a good example of this was the old "dumb terminal". I recall that the old ADM3 had a two-sided board about 16 inches deep by 14 inches wide, and packed full of logic. A 1980-vintage "dumb terminal" typically had a microprocessor, a ROM, a bit of RAM, and perhaps 25 TTL SSI/MSI components.

I'd be surprised if the logic for a current-generation "dumb" terminal, assuming that they even exist as products any longer, had more than a half-dozen components on its logic board.

If the purpose of the effort is to reduce the component count, microcontrollers rule supreme. After all, they can harbor lots of resources without increasing the cost by much.

I recently recommended a relatively expensive (about $8) MCU for a task that would have used a couple of dozen components, and therefore be considerably less flexible than it is now. It preforms several subtasks, each of which would have required a few pieces of "family logic" and analog components. As it stands, there's only one component, aside from power supply regulation and some connectors and passives.

I believe what causes most of the "jams" in which MCU application designers find themselves when they run short on resources, is that they've failed to analyze the problem to be solved. They like to design from the bottom up, rather than the top down. They say, "Oh ... I can do this like so ... and that I can manage like so ... ". That's bottom up thinking. That often ends in, "OOPS."

RE