In a few months, I might be switching to a team with a C++ project. A lot of the team is new to C++, and there's nothing about the project that needs C++, Java would have been fine.
Compared to Java, modern C++ isn't so bad. Dependency management and build systems are the main problems. Both of those should be solved in an existing project.
C++ has a lot of sharp edges. Skimming through the slides it seems as though Chromium hit upon a lot of the big problems because:
1. Google always seem to enjoy bucking the trend in terms of recommended ways to do things and end up using niche features that are likely to be deprecated
2. Chromium is a stupidly massive codebase so they have more things to fix just purely through scale
If you stick to the sane subset of the language that any competent modern C++ development shop would then you wouldn't encounter any of these problems except small/easy stuff like the new reserved keywords.
That being said, if you don't have a team that's already experienced in C++ then picking C++ is a bizarre choice.
This has never been my experience, and Joel isn't an all-seeing oracle.
In just one notable example, a company I was at had a team develop an important platform in Node.js when the rest of the company was hired for and familiar with Java/Ruby. This app ran our 3rd party API gateway and was a central part of how our company was attempting to grow.
The Node.js team left wholesale to go found CockroachDB, which left nobody at the company who had the expertise to take over. You'd think that someone at a fairly large company would have Node.js experience, but it wasn't the case that we could staff the team back up easily.
There were several major production outages and the app lagged behind in development for the entirety of its life. We also had to port our protoc changes and traffic stack just to serve this one app. This despite being a central part of our upmarket strategy.
Ultimately it was completely rewritten. And nobody regretted that decision. We carefully weighed the pros and cons.
There's something to be said for a company that standardizes on one or two languages. Letting engineers have free reign leaves you with Haskell and Erlang littered in important places, with a very tiny bus factor.