Most game projects I've been working on have had a really messy player class where everything is thrown into the same place. For My Neighbor Alice I decided to tackle that problem and was really happy with the result.
The mess often comes from adding features to the player, without considering how to modify or remove things later if needed. This creates a mess where everything ends up being all over the player code, entangled in each other.
By breaking the player class into modules, this issue can be mitigated. For MNA I split it into input, movement, animation, audio etc. since it was easy to make clean separations of those bits of code. The modules are then controlled by a player controller class which ties the modules together and handles the communication between them.
The main benefit of splitting the player up like this is that it keeps the complexity of each part of the code low. It’s also easier to modify for instance the animation code if you only need to look at the animation code, and not have to bother about for instance the movement code at the same time.