One product I updated replaced a chip with 8kB flash + 1kB RAM with an ARM with 256kB flash and 58kB RAM for the same money.

The change was needed because of a requirement to add CAN support. The const savings of being able to write in C instead of assebler was great. The previous chip required the assembler code to contantly jump into the middle of other functions for space savings (the chip manufacturer happened to get a one-year delay on the 8kB variant quickly requiring the application to be squeezed into the 4kB little-brother, and when the 8kB variant got available it wasn't meaningful to do a full rewrite). The extra bonus of the huge memory areas of the ARM part was that after matching the previous products capabilities and after CAN and a large set of additional candy functions had been added, the replacement ARM could still spend > 90% sleeping and with about 70% flash unused. Instead of switching to an ARM with less flash, the spare flash was used for storing two generations of the application while still having the two individual firmwares only consuming about 70% of their respective areas.

Within a specific family, more features or more flash represents a higher cost. When switching to a newer generation from the same manufacturer, or switching between families, there are no simple relationship between price and features or price and RAM size or similar. That is an important factor to think about instead of concentrating to hard on the fact that an assembler-written program can allow a smaller flash to be used. If estimating $100/hour, then a single week of shorter development time scales to 4k produced units at a device price difference of $1 - and if the price difference between two devices are zero then the $4k is a direct cost reduction even before the first unit is produced, besides the further economic gain of having a sellable product one week earlier.

What is so important here is that the 8051 has excellent support for bit operations and should always be at the top of the list if the majority of the application code is involved in bit conditionals or single-bit operations. But as soon as the bit operations does not represent a major part of the application, then the 8051 will be a processor among others, and in that case it will often come up wanting because so many of the 8-bit OP-codes where dedicated to bit operations that mainly memory addressing modes had to be skipped.

What I'm trying to say is that using C in an embedded device isn't just something done because the developers are lazy or unskilled but can often be represent a very major economical decision to reduce the development and maintainance costs. If I look at products I have worked with, the C-coded products may continue to be maintained for 5-10 years or more after they leave my table. The assembler-coded products almost always stays with me until supports is someday dropped. Few people really like to take over other peoples assembler projects even if the code is well-documented and does not contain tricky code to cut clock cycles or instruction count.

Assembler is the optimum route to maximize execution speed or minimize code size, but the percentage of products where it is econimical to hunt the last 10-50% speed and/or size is quickly dwindling and as a developer my main goals must be to prioritize maintainability and bottom line. A product that works well and draws in money is the best ticket to get the next job. And since each new processor generation gets cheaper or more capable, a redesign at half-time of a products life-span may be more economical than trying too hard at using the smallest processor in the first release and then have to keep that processor because the code would require too large rewrites to fit another chip at a later time.