It is not so much that a somethingManager is inherently bad, the problem is that the name is not distinctive, not descriptive.
It tends to quickly acquire secondary functionality, and tertiary functionality, and before long you discover that there are some global static instances of the object that many classes cannot live without, and it extends program startup for many seconds as you wait for all your managers to build complex systems before main() is even called....
Critically: What exactly is a "manager"? Remembering the Single Responsibility Principle, what single responsibility is covered in "manage"?
It generally depends on what is getting "managed". Often a "manager" is a group of items, this may be better termed a "cache", "pool", "store", "collection", or similar. Often they will have other responsibilities as well, such as loading data, saving data, queuing actions, unloading resources, or whatever else the person thought "manage" means.
The most cited type of "manager" people in games love to pull out is a resource manager. Normally for me I consider that four classes: A "store" that serves as the central hub. The store returns a "proxy", which may have the live and loaded values or may have fake values, but either way it will behave reasonably. The store has a "cache" that acts as the backing for data to a live proxy, and the store has a "loader" that manages getting data from storage/memory/network and into the cache. Again: FooStore, FooProxy, FooCache, FooLoader.
Similarly, someone may want to build a "ConnectionManager". But since "manage" is a terribly generic word, I'll look over their code and see if they meant to create a "ConnectionPool".
Other times they'll create what they call a manager, but on reviewing the class I'll discover it is really a collection.
The biggest problem is that these "manager" classes very often turn into a God class. They know too much about too many things, and very quickly spiral out of control into mega-classes that are difficult to maintain, debug, extend.
Thankfully so many tools support an automated class rename across the entire app and even between multiple apps, and it is easy to rely on your compiler to help in the process. Figure out the primary responsibility, rename it to match that responsibility. Anything that no longer fits the proper responsibility gets pulled out into its own block of code, also with its own single responsibility.