Just a quickie:
By the way: "There are things they can do ... but should they?"
Who are they? It sounds like you are not including yourself among "them".

The thread title is ""C gives 2K of binary for just a few source lines". Discuss."

The agenda I'm trying to push is that C is a very economical (not lazy) tool for developing embedded applications, and that the 8051 processor is no exception from that rule. It is one of the more HLL-challenged processors out there. But the compiler manufactuers have managed to make wonders. Knowing 8051 assembler will not automagically be enough to beat the compiler. And when the compiler ends up short, it will often still be in the neighbourhood. The compiler/linker can often to optimizations that an assembly programmer would not want to do, because such rewrites in the assembly code becomes too hard to read. The compiler don't have to care - it is enough that the code is correct, and that the C source is readable.

But you are doing your best to avoid any arguments:
- C generates too big code.
- C generates too slow code.
- C coders can't really program if they can't do it in assembler
- C coders who can do it in assembler but still do it in C does it because they are lazy.
- 8051 has so little code space that it isn't meaningful to look at different HLL.
- Keil C51 evaluation allows too little code space to be meaningful to evaluate.
- Cellular phones are a good example of why C results in buggy programs.
- C programmers are "PC programmers" where anything "PC" is your best insult.
- ...

The license may have expired on the 8051 core, but that does not mean that the 8051 is without economical competition. So if you do want people to use the 8051 to an economical advantage, they will have to make sure that they look at the full life cycle of the products. For a large number of products, or for a large part of the code inside a specific product, it is not economical to use assembler.

About C++:
"I did assume that you'd be unaware of them,"
Which seems to imply that you assumed that I would be unaware of them, making it worthwhile to try and attack my statement.

"...] a couple of C++ toolsets. I wasn't aware that their existence was so prominent."
No, I do not think they are prominent. I'm not sure if IAR got C++ support just because their compiler have C++ support for other architectures, or if it was a decision from the marketing department to make their compiler stand out. In the end, it is from the start a special embedded subset of C++, and even that subset will probably be hard to take advantage of on the 8051 platform. I say "probably" because I have never tested any C++ implementation on the 8051. I'm only speculating based on experience with the 8051 instruction set.

"When C++ was being introduced, it was touted as an advance for programming in the large."
When a new language gets introduced, a lot of people will try a lot of different marketing strategies. Some because people will like to sell new compilers. Some because people will like to sell training coursers. Some because people will like to sell books.

An important thing in C++ - and all other object-oriented languages - is the improvement of encapsulation. That is something you can get gains from in both small and large projects. In small projects, encapsulation can help with code reuse. But the huge money savings comes in large companies that are already fighting to get all their concurrently working developers from making changes that breaks someone elses code. Big companies had the most to gain from being early adopters. Big companies are also the ones who are easiest to sell courses to. But almost all sizes of programs are suitable for C++. A few hardware platforms are not so suitable for C++.

"I didn't realize that 'C' was inadequate and that large-scale programming techniques and tools needed to be introduced to the 805x market."
C is not inadequate. However, large-scale programming techniques and tools should always be looked at. A 10k line C program is still a program that can have a significant maintainance cost through the full life cycle. For a 8051, I don't think C++ would be a good way to go. But there are other tools that could be suitable to discuss in other threads. Such as tools for source code management. Tools for requirements management. Tools for regression testing. Tools for matching requirements with test protocols. QA stands for a significant percentage of the development cost, and that development cost can stand for a significant per-unit cost. It is quite easy to add new source lines for a new feature. It can be very hard to find and remove old source lines in case a feature is to be removed.