Private methods generally are a code smell anyway. If you have dozens of private methods in your class, something is probably wrong in your general design.
Private symbols reduce your public API surface, which usually means that it's easier to understand and use and has fewer code paths to test.
If your code is a collaboration of objects communicating via public methods, it's almost certainly going to be overly configurable (if it's using dependency injection) and thus be very hard to test every code path, especially given that consumers will probably be able to replace individual objects in the collaboration. It'll also be harder to understand, as objects which are broken out for modularity reasons show up publicly.
Minimizing public API surface is particularly important for versioning. If you don't control your consumers - if your API isn't fully internal to an organization and living in some kind of monorepo - then a big public API inhibits refactoring and feature extension as consumers take inappropriate dependencies on your implementation details.
In that case how to refactor a class that has 20 private methods? Moving them to another class and making them public would just shift the problem, not solve it
It's impossible to give a generic answer to this, it always depends on the specific domain. But I found that in these cases, there's always a design problem somewhere. Some responsibilities aren't clear, very often not much thought has been put into the design, and most of the time you can't give an immediate answer, which is why a bad design is chosen and causes a lot of damage down the line.
