Why is C++ not good? It doesn't grow memory usage on its own. If you can put C code on something, you can do C++ as well. We're talking about things up to 10 MB. It's perfectly fine on those. (actually the smaller your target, the less difference there is - you don't really have to care about APIs or calling conventions on an 8K chip)
Java has many different versions. For example the smallest one (JavaCard) can run on tiny chips in smartcards, so Java as a whole may be a bad generalisation, but it's definitely possible.
I find C++ encourages more pointer use by default, which implies all things are in memory at all the time.
C on the other hand has this less implicitly, so things such as handles, deferred messages vs straight method call, have less of a.. friction?
Now you can wrap them up in C++, but then making such things hidden I think defeats some of their usage.
A managed runtime should be handle this better, but I don't know of any Java or .NET runtime that is optimised for a small memory foot print, perhaps paging from a larger virtual space[1]. I'd be interested to hear of any really.
[1] I do know there have been versions of Smalltalk that did basically this, but nothing recently that I've heard of.
Honestly, I remember making less than a 100k binaries playing c64 sid and doing a whole bunch of other stuff about 15 years ago(I would have said 16kb, but I don't really remember the numbers). I believe I mostly disabled RTTI, but I wasn't very good at reading manuals and understanding C++ back then, so I ended up patching the compiler instead.
You could argue that if you end up disabling all the fancy stuff from C++ why use C++ at all. But anyway, you can definitely use C++ in low memory environments if you really want to.
You can write C++ code that works like an equivalent C program, but that code also looks like the equivalent C program -- only with slightly less modern syntax.
Writing good, modern C++ means using the external template libraries and all kinds of (relatively) heavyweight goodies. The trouble is it's difficult to predict the space cost of those goodies -- so on systems where that matters it's just easier to think in terms of C.
Regardless of if you're coding in C or C++ for micros, you're not going to be using much, if any, of the standard library anyways. You'll probably be rolling your own routines for a lot of stuff because so many libraries, even those for micros, are rather oversized for when you're truly constrained.
I've used templates in C++ libraries for the purposes of varying memory constraints and mcu capabilities. Being able to write a library once and deploy it on 8 bit and 32 bit chips without FPUs and chips with fpus means saving a lot of time, and it writes code that's just as efficient. Finally, a lot of C/C++ compilers for small devices have routines to give a pretty good guess as to how much RAM your code's going to need, so you can figure out ahead of time if a routine is really worth it.
You can use templates and objects at practically 0 cost, and significant abstractions can be built with these mechanisms. Presumably, this is a night and day difference for some people.
It's certainly the case that you can make use of C++ features sparingly and get the benefits of both C and C++; but I think the notion that "good, modern C++" is somehow supposed to be highly abstract and thus bloated up unnecessarily, is in itself problematic.
My original comment was more about the fact that despite using C++ and Java exampees, this book is quite strongly lacking any advice in the "use templates and other abstractions sparingly" direction.
Talk about using C++ rather than C for embedded code: https://www.youtube.com/watch?v=PDSvjwJ2M80 (code::dive conference 2015 - Bartosz Szurgot - C++ vs C the embedded perspective)
Java has many different versions. For example the smallest one (JavaCard) can run on tiny chips in smartcards, so Java as a whole may be a bad generalisation, but it's definitely possible.