"And C++ is explicitly a multi-paradigm language so there can be affordances for multiple approaches." - In other words, a jack of all trades and master of none. For a systems programming language, I'd want to be able to easily reason about where allocations, memory barriers etc are happening and I'd want an emphasis on correctness/verification (rather than ease of use). C++'s many abstractions, intended for applications programming, actually get in the way of systems programming.
This is essentially the same argument as "one can write secure software in C++". If it's not enforced by the language and tooling, one can't safely assume anything.
We just spent half a century proving that discipline never completely solved the problem. We can’t afford platforms in which a tiny mistake anywhere causes unpredictable failures in unrelated and correct code, and we can certainly afford the lifetime and bounds checks that prevent this.
So, use modern features that don't encourage mistakes. Most C bugs come from mistakes with pointers; in good modern C++ you rarely see pointers, and can afford to focus all the attention needed where they do appear.
I just glanced at Lohmann-JSON which just uses them for the json elements themselves (there’s a comment that says “raw pointers to save space” and spdlog and fmtlib which appear to use them only to interface to C APIs and *this. That was just a quick glance at some libs we use.
I have seen them used in the PIMPL idiom, which is a rather controlled case.
Here is a program that solves the New York Times puzzle "Letter Boxed". Its only uses of pointers are in processing main()'s arguments, which are provided via pointer, and mapping an input file, which Posix provides via a pointer. It does use std::string_view, which has pointers in it; the point is that you don't operate directly on the pointers, so cannot have bugs caused by misusing the pointers.
Thus, the word "view". It refers to storage being managed by the creator of the string_view object, in this case a file mapped using mmap and not unmapped until after program termination.