As @normalized said, you don’t need one. Everyone who uses Godot is technically using one, as that is what a game loop is. It’s a state machine that just rolls through states 60 times a second.
We talk about state machines on this forum a lot. In this particular post I go into great detail about some of my own uses of a node-based pull state machine. I think it will answer many of your questions. The code is in my State Machine Plugin if you want to study the code, or try out my state machine.
But also, here’s some direct answers to your questions:
That depends on the kind of state machine you make. A push state machine is one where the machine decides what state should be active and pushes the states to enter. A pull state machine has the logic of when a state is entered inside each state, and pulls the state machine to enter its state. Either way, the state machine is supposed to handle transitioning between states. The states are responsible for the logic of what happens in that state.
Encapsulation. To reduce the amount of code in a single file, and put related code in smaller pieces. As in you example, you take all the Jump code inside the Player and move it to a Jump State. If you decided to add double-jump functionality, you can then either add it to the Jump State or make a new Double Jump State. Either way, as that functionality gets more complex, the code in your Player doesn’t have to contain it all.
This question is unclear. An Enum-based state machine doesn’t usually use composition, and usually sits inside the Player script. A Resource-based or Node-based state machine typically has a Resource or Node for each State and so uses composition.
This is an example of a complex state machine for a player.
Note I have two state machines. One for movement, and one for actions. But for your example, I just have movement logic in the Jump and Fall states and call it air control. One of the other benefits of a node-based state machine is it is easy to see all the states in the editor. Another is you can tweak each state with @exported variables.
Personally, I like node-based pull state machines. I find them easy to use once they are developed, and I make a lot of games, so it pays off for me to do the work once, re-use it, and improve it incrementally over time. For example, I use it for what state the game itself is in as well in my Game Template Plugin. But, I don’t always use them.
Conclusion
I think it’s worthwhile to ask yourself, why do you want to use a state machine?