Most of 8051 books don't get old. Except when they recommend tools or what chip to buy.

A very significant amount of embedded work are now done in C.

With todays product life spans, the developers times represents a very high percentage of the total costs. And the cost of processors are not a strict linear function based on amount of RAM or code space. And power consumption is more a function of processor generation than it is based on number of tranistors.

So both for hobbyists and for commercial work, C are a very much valued tool. Especially since large percentages of the business logic can be moved from one processor to another with almost zero work - it's the mapping to UART, timers etc that needs to be adjusted when moving to other manufacturer or totally different architecture.

When the last byte isn't important, most people will quickly find that only few percent of all embedded programs (or actually fractions of programs) needs to really count clock cycles. So while majority of embedded C programs don't have any assembler except for the startup file and some optimized functions in the CRTL, a much bigger percentage of applications can squeeze the required performance by having maybe 10-100 C lines converted into assembler.

The main goal is normally productivity. And correctness. Where C have advantages in front of assembler. Or where hw-assisted debugging have big advantages over monitor-based solutions. Why look at an unformatted hex dump from a monitor, when a in-circuit debugging with a debugger integrated with some debug-cells in the chip can instead show fully decoded information. Of course it's a disadvantage when the debugger needs to be matched to the hardware - but the advantage in productivity is high. And haven't Keil been working on XML-based templating for getting their debugger to present information for unknown peripherials?