Well essentially cause it's used in large multi threaded projects to protect shared data by casting to it. From a semantic stand point it makes more sense to cast the function argument to a const pointer rather than the function itself. Const function members implies the function is run exclusively on the heap, and it may not modify any members of its class unless they're static. It probably doesn't inherit the internal this pointer either because of that mechanic, as there is no guaranty the class was allocated in the heap or the stack. Most are in the stack however, which is also a problem in heavily multi threaded projects where you have limited heap available, as each thread usually has its own static amount provided at spawn. In such projects you try to stuff as much as you can of your memory needs in the stack.
There's a matter of speed as well. Memory allocation is very resource intensive. Again, with a lot of threads (100+) you'd be giving up quite a lot of cycles to memory management by using anything allocated in the heap, which implies dynamic content, so alot of internal alloc/free. Keep in mind that in most languages, memory allocation implies locking and memory fences. Quite expensive alright. It would be a ressource nightmare if you'd pass entire objects as arguments to a const member function instead of a pointer. This is however profoundly counter intuitive as people tend to do this a lot, thinking "hey, im within my class". As a matter of fact, I see it a lot with operator overloading.
As far as the member part goes, my understanding was that you're expected to use the public/private/protected nomenclature with class inheritance to achieve proper data isolation within your classes, like let's say, to protect a semaphore through polymorphism.
Then again C++ is one of those languages that chooses to allow you the freedom of shooting yourself in the foot rather than forbid certain combinations at the cost of semantics.