...but it's still standard practice to use private extensively in code today, as it does provide a lot of benefit...

Common practice doesn't mean a lot; most programmers never ever question the habits they got used to, while learning to program. As such, you mostly observe patterns teached a decade or so ago.

A good example is setters and getters in Java.
Every Java tutorial you get is filled with them. As a result, you see everybody using these functions, even if they don't really add anything. If you do "public void setX(X newX) { this.x = newX; }" you can just as well drop the setter and getter, and just give access to the variable itself, since you're protecting nothing. There is one exception that I can think of, namely if you write a library where the public API accesses variables, and you want to be able to update the library without breaking the programs using it.
I know they're supposed to enhance modularity, but I have yet to see a case where you change the inner working of a class where the surrounding code isn't considered or touched. And it's easy enough to refactor abstraction/getter/setter functions in, if you need them.

So in most Java code, I don't see the need for getters and setters at all. Yet you continue to see these functions everywhere.

I do agree having protected/private is useful to guide intended use of the API (and I do miss the C++ protected notion in Java every now and then).
On the other hand, It's just guidance, something that can easily be expressed in a line of comment.

That example is just a tad different though -- private exists specifically to help with the implementation of OO designs, while, naive getters/setters (the type that perform no operation other than making a private member publicly mutable) actually do the exact opposite and fight against OO design principles. Java was founded on not giving a shit about academic OO design theory though, so it's no surprise that anti-patterns are rife within it's ranks
A class's public interface should provide a useful abstraction over the top of it's private members -- if it does not (such as in classes with naive getters/setters), then it's a very strong code smell.

Even though C++ is lame in that the "header" files typically contain both the public interface and the private implementation details, this doesn't mean that private is still provides no benefit. Private/public exists to separate the code which provides the "useful abstraction" from the code that enforces the internal class invariants. Assuming that public/private has been adhered to throughout the project correctly, then when, as a maintainer, I receive a bug indicating that a particular invariant has been broken, then I can instantly narrow down my search to the private members which enforce that invariant. Assuming the codebase also follows other common practices, such as the SRP from SOLID, then that should leave an extremely small part of the codebase that requires my scrutiny.

Maintaining large codebases where the authors have not adhered to this kind of common practice is hell on earth.

p.s. protected is also a code smell