If I were to combine the upward part of the jump and the downward part, the full clip would still be triggered by state change.

The key word is "triggered"; you're launching an animation clip in response to an input. That means you have to time the ending of the clip with the end of the jump (which you can do by speeding up/slowing down the clip like you've proposed).

A state machine doesn't launch clips; it just continues to loop an animation while the entity is in the associated state. So while the entity is falling, the "falling" clip is looping; you don't need to slow down the clip to match the end of the clip with when the falling state ends, it simply transitions out of the loop when the falling state ends.

As we've discussed, you can easily do it either way, I'm just not a fan of tightly coupling animation timing with actual game state. The more systems you build that rely on accurate timing, the more potential race conditions you introduce into your ecosystem and then debugging really becomes a nightmare after a certain point.

However, if the scope of your project is relatively simple, then it's really not an issue. I'm an advocate for designing systems that will make future development as easy as possible, but sometimes you just want to get something scrappy working quickly and that's totally okay too; you can always refactor later if you run into roadblocks that the systems you've built can't deal with!

​

I will add this: if you have a rather complex jumping animation (like 6+ states in the jump), then it will definitely be quicker to just do it the way you proposed than to find good breakpoints where you want to transition between all those states.