In today's environment, it's hard to guess whether small or fast, or both will yield a "best" solution. After all, if speed is essential, then the code that runs fast will be better if it gets the job done on the small cheap MCU. if the $1 chip can do it, particularly with its limited resources, then I'd consider the code that works on the $1 better than the code that won't. If low power is essential, the high-speed MCU might just use too much power. If communication with an external peripheral that is slow is necessary, and budget doesn't allow using a more generously provisioned MCU, then perhaps the code that does the job at a rate compatible with the desired peripheral is "better" than code that demands more memory, resources, cost ...

It isn't always that way, but it happens often enough. My work has always been centered around making what I've got available do the job, rather than finding something that will work. I work on a short time-budget. As often as not, I'm limited as to MCU choice by the existing hardware. I can use a drop-in, hence my interest in the Maxim/Dallas 89c4x0's, or some sort of adapter, much of the time, but the thing that saves me is that I can whittle on the code in ASM where precise timing is required. For me, that's vital. For others, perhaps not.

If I have 805x code that works, I have no motivation to move to ARM or to AVR. Aside from that, I'd never use an AVR until there's a second manufacturer.

Those premises won't apply to every one.

RE