Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.

Do not post blatant lies.

You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.

And in practice assembly has the performance disadvantage of not being subject to most compiler optimizations, often including "introspecting on its operation, determining it is fully redundant, and eliminating it entirely". It's not the 1990s anymore.

In the cases where that kind of optimization is not even possible to consider, though, the only place I'd expect inline assembly to be decisively beaten is using profile-guided optimization. That's the only way to extract more information than "perfect awareness of how the application code works", which the app dev has and the compiler dev does not. The call overhead can be eliminated by simply writing more assembly until you've covered the relevant hot boundaries.

We try to catch things before public release.

We run UNSPEAKABLE amounts of regression tests.

We ask people to test unstable things.

Almost no one actually does test the unstable things. There's too much friction.

Almost no one actually gives us feedback on them. There's too much friction.

Things land on stable, people FINALLY actually mass-use them, the stable thing turns out to be busted, and THEN people overcome the friction to complain because they (rightly) fear it is going to be unfixable. Sometimes it is. Most of these have been very minor so far, and only affected things easily rolled back, but there will come a day when it is not so minor and not so easy to roll back. And nothing we can do in simulation or stress-testing on our end can replace contact with actual programs.

We're not making a typical "product" here. You can't think of it in typical product terms. We're making a programming language here. A contract, effectively, though not a legal one, as it is itself a system of expressing contracts. We cannot simply roll back things that are part of the language's contract in our stable releases if something is flawed, unless the flaw is SO dire as to result in one of the handful of situations that allows us to break it anyways.