Maybe I'm showing my age, but I remember the good old days. The first processor I programmed for was a 6502. Followed by a list of other illustrious 8-bit processors, like the 8088, the Z80, and the 8080. All either in assembly or a mix of assembly and Pascal--remember Borland, anyone? Sometimes assembly and C. Then came all their 16-bit friends, which were more of the same ilk. Life was simple then--there wasn't any code in the system that you didn't write. Total transparency. And total control.
But the good old days weren't always so good. The romantic simplicity of those times is overshadowed by the memories of all the hassles and engineering challenges in dealing with those 8-bit dinosaurs. The constraints on those processors were huge: very little memory, very sparse registers with dedicated functions, and arcane mixes of available instruction/register combinations. Lots of time packing and repacking functions, rewriting to save every spare byte because the chip couldn't address any more than a squeak of memory. Making your code impossible to fix or edit, because you had a clever trick to save ten bytes by manually chopping out snippets out of the generated assembly. Confusingly overloading functions, inexorably linking code for two totally unrelated purposes, like the calculating the display column offset and delaying for proper timing of an A/D read. You know... in hindsight, those days were truly awful.
Still today, although the 8-bit well has almost dried up, companies are selling and creating products that use 8-bit and 16-bit processors, when 32-bit and 64-bit processors are available.
The answer is easy--cost.
Unbelievably, it's still cheap to make those antiques. Either that, or there is just some warehouse in New Jersey that's piled ten stories high with the junk. Having known how difficult it is to squeeze some life out of these tired old dogs, I can only pray that they just go away for good.
Because I care about software engineers and their mental health.
The true cost of programming for 8-bits is lost productivity. Engineering time is not cheap, and although it often isn't considered, an accurate cost assessment needs to amortize engineering effort over the life of the product. For a consumer electronics device, the life of the product is preciously short, and for every cent you save on using an 8-bit processor, you add a dollar's worth of engineering time to the bill of materials. In the brave new 32-bit world, productivity is amazing--you can crank out code in a fraction of a time using modern tools, libraries, OSes, and applications frameworks. 32-bit tools can completely blow away what is even possible an 8-bit micro, all the while the other guy is still debugging his old fashioned bubble-sort routine.
For the sake of software engineers everywhere, let 8- and 16-bits die, once and for all. I'm there for you, you poor non-32-bit engineers. Until that day.