That's right. This is WinAPI's message box function. LPCTSTR in case you don't have WinAPI experience, is pointer to string. WTF? This function doesn't even NEED pointer to where string is stored as it doesn't change it. It only show standard Windows message box.
LPCSTR is not a pointer to a string. It is a string. It is an array of null-terminated characters.
C does not have a string type, so the standard way to represent a string is by using an array of characters, which decays to a pointer.
There's nothing wrong with QMessageBox::about. If the partent was passed by value, that would clone the parent and the message box would be attached to the clone instead of the original (desired) parent. The intention is to share a single object in multiple places, so a pointer is required.
The strings are passed by const-reference, which is the same as a pointer, but with the guarantee that they won't be modified, so it looks just like pass-by-value. The difference is that pass-by-value would create copies of the strings, which is a complete waste of time. If the API required that all string arguments be reallocated for no reason, it would be a bad API.
The SDL_Surface is allocated by the API and reference counted. The object that's pointed to by your return value is a shared object, more than one part of the code may be pointing to the same shared object. Returning by value would completely break this shared-asset design.
I appreciate your pascal joy and your dislike of C ... but your critiques of "bad" C code above simply show that you haven't learnt C or C++ yet and aren't qualified to critique those APIs Critique the language that results in these API designs, fine , but your supposed API flaws are not flaws.
P.S. I enjoyed using the "become equal to" / "assignment" / ":=" operator, rather than "=", which mathematically means equivalence, not assignment.