If that is your main argument, then you are saying that:
- you don't expect your products to live on.
- the product life of your products are measured in minutes, and not in decades.
- your hardware design are such that if the customer needs an update, a hardware change is likely.
- you don't care about documentation.

The use of C instead of assembler means that a large part of the code can move to a different processor.

Quite a lot of companies do care about their investment and want to:
- keep the product alive.
- add new features if needed to defend their market shares against competitors
- keep down the maintainance costs
- reduce the initial development time
- minimize the initial bugs in the software - especially important for cheap products which high fw update costs

The relative ease of moving between processors (and even processor architectures) means that a high-volume product can switch processor more often, depending on the availability of new, cheap, processors. For the type of products I work with, the generation changes are often introduced to cut hw costs by constantly looking for alternative hw components. The use of well-designed C code allows this without starting from zero. The products may ship in 10k volumes/year, and a hw redesign is often financially covered very quickly. Translating the source-code mapping of UARTs, timers, GPIO, ... is way faster than starting each time from scratch.

I have worked for a number of companies, both as consultant and employed, and just about every company have cared a lot about their investments. They want to ship fast, so they like tools intended to cut development costs. And they want their maintainance costs to be low. And they want their investments to live. They often need good documentation because of certification processes, which means that they also wants their documentation to live. I do not think my experiences are unique. A very large percentage of companies do want the bulk of their code written in a high-level language, even if they intend to ship 10k or 100k volumes each year. Day one, your bytes saved by use of assembler may (possibly) save them $0.50 from using a smaller chip. Day 300, the use of C may allow them to save $1 by switching to another processor, or maybe keep the processor price but switch to a processor with a CAN interface or a second, third or fourth serial port or a 12-bit ADC or an RTC that consumes a fraction of the power, allowing a smaller battery. When writing the application in a way where there is comparatibely cheap to move between processors, the big issue is still that the cost of a processor is not proportional to the amount of memory. Such cost issues are only relevant when you are forced to stay within the same family of processors from the same manufacturer. You may save $0.50 by moving to a chip with twice the amount of memory, if you are allowed to jump to a different manufacturer.