Ah, you're making the common mistake and assuming it's for creation, that's an import tool, as well as a tool for syncing animations within the engine to inputs. Generally what I'm talking about is content creation middleware, they don't have to list every tool they use in a project. Generally it's an Autodesk Animation Suite because those are industry standard. That's what creates the animations, the gamebryo animation tool is what imports them for use in the renderer.
It's not powerful, because it relies on the other tools and the users being competent. Gamebryo is incredibly barebones, and is generally only used because licensing it is cheap, and they have premade bindings for most common middleware.
Source: When I was attempting at one point to make a game, I bought a license to gamebryo 3 thinking I could recreate/make a game like Morrowind with it. Unless a lot changed with version 4, which I doubt, it's a massive pain to work with.
However, Josh said that the problem lies with the way the engine handles blending which is a Gamebryo-side problem. Additionally the Divinity Anthology comes with videos of behind-the-scenes stuff and I remember a moment where they show a pig rolling around with far more fluidity and detail than pigs do in the game itself, so something happened between "bullshit example for investors" and "finished product."
I'm not quite sure how to say this, but, as it requires a fair bit of knowledge of animation to understand, ask me to clarify if you get confused. As it is I'll try to explain concepts as they come up. And to keep it fairly basic.
Animation, as in the movement of 3D objects through space is hard to do dynamically in a self updating process. The standard style of animation, used by pretty much everyone in the industry is keyframe, even if you have Mocap it's usually converted by hand to keyframe. The holy grail, of late, animation wise is procedural animation, like the kind the folks at havok, autodesk and lucas arts have come up with independently. Each of these use physics schema to examine how an actual limb would constrain to the motion, and then attempts to animate it. Still in these systems, because they can't realisticly model things like a walk cycle using physics, they hand animate, or convert mocap. Any animation at all is done on the CPU, and yes it's generally done on the CPU not the GPU. Unless you have the good grace to have a PPU or an Nvidia SLI array with a card dedicated to physX. Then generally those packages above will work with that. But only if they are utilized. So when you see initial product offerings with smooth animations, and such, and then discover, in the actual game the animation is far worse, this is due to the realization that the hardware likely can't handle it. Oblivion, Div2, and the recent fallouts were all designed using traditional non-physics based keyframe animation. Which requires something called transition frames. Transition frames are not something done automatically, they are generally done semiautomatically then tweaked, in most modern SDKs, in gamebryo 3, the automatic generation is nearly borked and only works half the time, and it's suggested to do manual, however, doing a purely manual generation of transition frames is mindbogglingly hard, time consuming and relies on a lot of skill and patience to avoid a phenomenon called "Jumping" if I remember right, where there are gaps in between an animation and the next. I know for a fact that until Skyrim(Allegedly), Bethesda as a publisher, and by extension Obsidian as a developer, were using version 3, not version 4, which wasn't stable at the time of those games creation(It was only released in July last year.). I honestly believe this is why Bethesda has hard coded most of the animations in the game. Theres no real automatic generation of transition frames, so you end up with a jump at the end of the animation as it goes back into a basic standing or another basic frame(Look at oblivion animation mods). The other thing to note, is that the production standard for animation frames is between 14-24 frames per second depending on the style of the game and the studio in question. Skyrim mostly solves the transition problem, by implementing the Havok Animation Suite, or possibly Autodesks Solution, I can't recall. This means animation replacement is much smoother, and all the transition frames can be generated from real life physical constraints on the body, procedurally with only a cursory look over and tweak. If they set up their editor correctly, I don't own Skyrim PC edition at current, so I can't really tell if I am assuming too much.