First off, I think every project should be started without bias when looking for a processor to use. And in the same way, the requirements of the project should decide if assembler or C (or possibly something else) is the best choice.

I haven't had the time to reach that final state of guru for any processor for the simple reason that the processor deemed "best" has always varied from project to project. I have done embedded work with 8051, Z80, AVR, PIC, PPC, ARM, x86, 68xx, 68xxx, ...

This means that I always need the assembler reference very close at hand when writing assembler, but can manage quite well with just the user manual/datasheet when the project is using C.

In some projects, there have only been one or two processors fulfilling the requirements so there hasn't been any possibilty of selecting family. In some projects, one processor has been significantly cheaper which is the major factor in high-volume products. In other projects, the over-capacity of some processors has allowed significant reductions in development and maintainance time and cost leading to lower life-cycle costs even for 10k+ volumes/year.

In the end, I normally end up with well-working software that manages the task and normally have space and time to spare for a couple of bonus features. Once or twice, the project has needed to switch processor - either because the customer has decided to suddenly change the requirements (this is a good time to pray that the project selected C) or the chip manufacturer haven't been able to supply the chips at their promised date or have possibly "forgotten" to mention some little damaging "gotcha" in the datasheet or errata.

But a note about 8-bit operation. It is not so simple as to think a 32-bit one-clocker and a 8-bit one-clocker will have the same speed when solving 8-bit problems. Richard was happy about being able to load and increment in a single instruction. I responded by noting that all "real" processors can. But better processors can do better than that. They may be able to increment the pointer by arbitrary values for example. So if you have an array of 34-byte large structs, and pick up one byte from each array entry with just a single load and increment instruction.

Some 8051 can alternate between two pointers, but what if you have a huge LED display that needs to read data from two bitmaps and merge into a third? Where do you get the third index pointer from? A more GP processor core can just select a (any) third register and use (with auto-increment).

How about accessing fields in a struct, by processing data with pointer + offset? A bigger processor can do the offset fetch and add without a single extra clock cycle by reserving offset bits in the bigger instruction.

Shifting 8-bit data halfway into another register? With 16-bit or 32-bit register width, there will not be any need to do multiple shift into carry, shift from carry - instead a single barrel-shift can jump-shift multiple steps in a single clock cycle.

I think the 8051 will be heavily used 10 years from now too, but I do not think anyone should select processor just because it belongs to family "x".