Perhaps the useful angle on this isn't really about security, but instead that it's misleading when resources for learning C++ say "private data can't be changed by other code". In a way that's the purpose of "private", but it's more accurate to say "C++ doesn't allow changing values via a private variable in other code" and "'private' is a tool for stating the intent of a variable in a way that compilers will often enforce".

In the C language, "const" is a tool for stating the intent of some data, but in many cases code can just remove that "const" with a pointer cast and modify the data anyway. It's useful because it makes it harder to accidentally do what some other code (by someone else or yourself) advised not to do. Really, unless you're writing assembly code or direct byte instructions, *every* language feature in a language like C, C++, Java, Rust, etc. is a tool of this sort, while in fact you can still do anything the OS and hardware allow.

There is another approach to programming languages with strictly defined limits on what code can and can't do. Lua is one example, often used in games to allow users to write code and still know their code won't cause crashes or do naughty things. That requires a separate interpretation layer at runtime between the OS and the Lua code, slowing down some things, so it's not appropriate for, say, complicated mathematical computations. C++ and its kin have a philosophy of staying "close to the hardware", or "make all things possible and common things easy". These language categories are separate use cases, both useful per situation.