I'm a bit curious why the capsule being drawn doesn't seem to align with the collidable it represents though. As in there's a gap of 0.3-0.5 between the bottom of the capsule and the ground.
The SimpleCharacterController is kept off the ground by a ray cast. That allows it to support a form of stepping, though unsafely.
And what about for non-FPS style characters? My game will be a third person action/strategy. I assume that'd be the same character though, just different camera?
The camera perspective is indeed irrelevant to the character controller. If the character controller itself behaves like the usual FPS character, then the CharacterController or SphereCharacterController is the way to go. The SimpleCharacterController is almost always worse regardless of the goal.
An example of a game where the CharacterController isn't really necessary would be Starcraft 2 and other RTS games. The characters do not need to do much. Their modes of interaction could be more efficiently handled by a highly specialized implementation that doesn't even have a general physical representation (they usually have some inter-unit collision detection, but that is a long ways from being a full physical simulation).
Out of curiosity, why is the sphere character more robust than the simple?
On a high level, it's because the SimpleCharacterController is enormously old, built for a long-obsolete version of the engine where it was difficult to do the things the newer character controllers do.
An overview of the characters can be found
here:
However, the SimpleCharacterController has a couple of problems. First, as mentioned, it does not try to protect itself against step ups. It has no way to recover from a bad step. Second, since it relies on a single ray cast, it can fall into tiny gaps. The CharacterControllerConvexCast addresses the second problem. Instead of a single, thin ray cast, it casts a disc down. However, it still has no way to abort a bad step-up.
There do exist environments in which the SimpleCharacterController won't suffer from severe robustness problems, but there's no advantage to using it over the SphereCharacterController or CharacterController. Rather than relying on a single ray to find support, the new characters analyze all their current contacts for persistent support. They use rays for occasional supplementary tests, such as when the character goes down steps.
In addition, the SphereCharacterController and CharacterController both use constraints to move around. That means their movement forces can be fully seen and understood by the solver; they can interact with articulated structures with a great deal of robustness.