I don't think that article is particularly outdated. The subsequent development of and cost drops for ARM Cortex-M processors has changed the scene a bit - but they had ARM V7 TDMI units then which were comparable.
But at no time has UML tooling been the driving factor behind the industry's adoption or lack of adoption of a language.
The problem with C++ and other high-level languages has always been that it's hard to see how much a line of code costs. Incrementing a pointer to an array in C has a transparent, short runtime, compared to moving to the next element in a C++ collection which may accidentally invoke a dizzying indecipherable mess of template objects, overloaded operators, and STL dependencies. Or in other languages, you may need a large operating system and runtime to be loaded.
High level languages do handy magic things for you under the hood. If your engine bay is measured in terabytes of storage, gigabytes of RAM, gigaflops of computational power, hundreds of watts of electrical power, and seconds of acceptable interaction time, those magic things that let programmers build useful features faster are nice.
But when you're trying to get guaranteed responses in microseconds from milliwatts of electrical power in a few kilobytes of RAM, you're likely going to be hand-picking everything under the hood. No magic allowed.
I didn't glean that the author is implying UML influenced language choice, just that UML vendors tried to sell to C developers.
But to answer your question, C++ is gaining a larger foothold in embedded if anything. More and more libraries are written in C++, and it's becoming more supported in the various toolchains.
From a very recent hackaday article -
"Modern C++ allows us to write cleaner, more concise code, and make the code we write more reusable. The following are [...] new features of C++ that don’t add memory overhead, reduce speed, or increase size because they’re all handled by the compiler [...] after reading this you’ll be more aware of the newer features as we start to see them roll out in Arduino code."
And also, because I was poking around their github today, here is Flybrix's source code, a lego-drone startup writing C++ on a Kinetis K-20 microcontroller (100 MHz ARM Cortex-M4). They use the teensy bootloader, which is why you see a mix of Arduino and C++ files
Embedded C++ has been a thing for a while. The bigger issue is that one of the major compiler vendors only provides pre-standard C++ with no namespace std. C++11 is a pipe dream if you can't switch to a modern compiler. Still good enough for C with classes.
But at no time has UML tooling been the driving factor behind the industry's adoption or lack of adoption of a language.
The problem with C++ and other high-level languages has always been that it's hard to see how much a line of code costs. Incrementing a pointer to an array in C has a transparent, short runtime, compared to moving to the next element in a C++ collection which may accidentally invoke a dizzying indecipherable mess of template objects, overloaded operators, and STL dependencies. Or in other languages, you may need a large operating system and runtime to be loaded.
High level languages do handy magic things for you under the hood. If your engine bay is measured in terabytes of storage, gigabytes of RAM, gigaflops of computational power, hundreds of watts of electrical power, and seconds of acceptable interaction time, those magic things that let programmers build useful features faster are nice.
But when you're trying to get guaranteed responses in microseconds from milliwatts of electrical power in a few kilobytes of RAM, you're likely going to be hand-picking everything under the hood. No magic allowed.