What is difficult about checking pointer addresses against safe memory boundaries, or is the difficulty doing it as fast as unsafe C++ ? Well, it's a compromise.
There's address sanitizer, and languages with garbage collectors and runtime bounds checks. There are WASM VMs, and even RLBox that translates WASM back to C that checks its own pointers at run time.
The difficulty is shifting most of these checks to compile time. Proving things at compile time is the holy grail, because instead of paying run-time cost only to make the program crash sooner, you can catch the violations before they even make it into the program, not pay any run-time cost, and provably not have such crashes either.
But that needs reliable static analysis, and C++ doesn't have enough guarantees and information in its type system to make that possible with a high degree of accuracy in non-trivial cases. This is not a matter of writing a smarter tool.
Statically tracking how pointers are used quickly ends up infeasible: every if/else doubles the state space, loops can mix the state in ways that makes symbolic reasoning provably impossible (undecidability), pointer aliasing creates lots of nearly-useless edge cases, and everything done through "escaping" pointers adds the state of the whole program to every individual state analysed, quickly reaching limits of what can be proven. For example, if use of a pointer depends on obj->isEnabled, now you have to trace back all paths that lead to getting this obj instance, and all the code paths that could modify the flag, and cross-reference them to know if this particular obj could have this flag set at this point in time... which can be infeasible. Everything ends up depending on everything, and if you give up and mark it as "unknown", it spreads like NaNs making the rest of the analysis also unknown, and you can't prove safety of anything that is complex enough to need such proof.
Rust and Circle/Safe C++ solve this problem by banning all cases that are hard for static analysis (no temporary pointers in globals, no mutable aliasing, no pointer arithmetic without checkable length, strict immutability, and single ownership and lifetime of memory is baked into the static type system, rather than a dynamic property that needs to be inferred through analysis of the program's behavior). This isn't some magic that can be sprinkled onto a codebase. The limitations are significant, and require particular architectures and coding patterns that are compatible with them. Nobody wants to rewrite all the existing C++ code, and that applies to not wanting to rewrite for Profiles too. I don't see how C++ can have that cake and eat it too.
