First of all, a talk by Microsoft (home of maybe the most confusing and awful C++ compiler in existence) is not a great place to start discussing C++. They are a total clusterfuck as far as what they support and I am sure that bleeds into the way they write code. I would go so far as to almost call their implementation "not standard C++", since I honestly don't know what they would describe their level of compliance with the standard to be. They seem to cherry pick features from whichever standard they feel like and implement them without implementing others, and every time I write C++ targeting MSVC it is a fucking nightmare to try and 'dumb it down' from normal C++11/14 intended for GCC or Clang. Microsoft seems to view C++ as a backup tool that you should use when C# isn't fast enough, rather than looking at C++ as a first-class language.

But moving past that, most of what you describes sounds like honestly either misunderstanding, not understanding, or just not liking the language on a subjective level. You bring up move/copy semantics over and over again (in fact, that's almost the entirety of your post, since things like making 'temporaries' are related) - they aren't that bad. Know what an lvalue and an rvalue are, write a couple move/copy constructors, and you are basically good to go unless you go WAY out of your way to create some weird situation where things break.

To go over the example at 26:44 - without even listening to the talk, it was immediately obvious what they did wrong:
1. Used raw pointers to manage member resources, necessitating the need to manually manage resources in the constructor/destructor (and to have to write a destructor in the first place). Smart pointers would avoid this.
2. Moronically (and in a completely contrived and ridiculous fashion) initializing those variables to nullptr and then immediately trying to set them to other pointers which rely on constructors in order to be valid. If the constructor for A or B fails to execute, memory is leaked. If you thought C++ was Java, this might be confusing. Since it's C++, this isn't confusing if you ever read the manual.

Aaaand after going back to watch the video, that's exactly what they said. So how does this example prove that C++ is bad, or 'needlessly' complicated? If you follow what the manual TELLS YOU TO DO ("The C++ Programming Language" by Bjarne Stroustrup), then you will NEVER write a class the way the 'bad example' showed. It explicitly, repeatedly tells you not to do things the way they set up that example. So literally the only reason you would ever be in that situation is either you never read the manual and don't know what you are doing, or because you absolutely know that you need to do stuff that way and are willing to do what it takes to be sure it works. C++ gives you the OPTION of writing cancerous, dangerous code if you absolutely must do it - but everyone who knows how to use the language will tell you not to do that stuff.

I mean, I know you say not to call your examples artificial, but they ARE. It's people going out of their way to be like "hey guys, hurr durr look how confusing things can be if you write code like a madman!". It doesn't prove anything other than the fact that C++ gives you the ability to really screw stuff up if you bumble through your code and ignore all the instructions that the writers of the language told you to pay attention to (and, I suppose, that pre-C++11 was a bit of a mess). If people can pick up Python or whatever and just churn out code writing as haphazardly as possible and not have stuff blow up, then great - good for Python. But C++ is not the tool for people who don't want to RTFM. Criticizing it because the complexity can let inexperienced programmers fuck stuff up is like criticizing solar panels because someone could theoretically wire them up in such a way that would cause them to catch on fire. Yes, people get 'tripped up' by the complexity of C++. That does not prove anything about how C++ 'SHOULD' be.

This sort of brings me (finally) to my point: if you are going to criticize C++, then offer specific examples of specific things in the language that should be done a different way, and which COULD be done a different way without rendering C++ unsuitable for a number of industries. Not just 'they should be like Rust' - what is a specific part of C++ that is complex or confusing for NO GOOD REASON? Because again, the manual covers the fact that people complain about the complexity. C++ is complex because it has to be in order to fulfill its purpose. It is used in so many different contexts that it has to be able to do some really weird stuff sometimes in order to function. You may not think about it when you are writing the logic for a desktop app, but people writing code for some 17-bit custom CPU somewhere are going to need all the arcane low-level stuff, even if you can get by with STL classes. They might need to do stuff that violates some abstract concept of 'purity', but which gets shit done on a system that nobody else has ever worked with. If you think Rust will ever have a chance of usurping C++ without also taking on a lot of that complexity, you are deluded. Let's see how Rust looks in 30 years if it's the industry standard used on billions of devices. I can basically promise you that people will say the same things about it as they say about C++ now, and there will probably be some new upstart language trying to simplify Rust and make it more accessible (and this is a good thing, because this is how we make progress - we build what we need, and then try to reshape it into what we want). Rust seems to me to be sort of the 'next wave' of C++ style languages, but if it is, then the reason it isn't complex yet is because it isn't done building out the functionality it would need to really achieve its potential.