Starting from a position in the world and then picking an animation based on that position and movement makes sense from a software engineering stand point. After all, the animation is – mostly – just a visual concern.
This approach will allow for more freedom in animation. And that is good if you want stylized – not so realistic – animation, useful to convey character personality, which is something you want in order to have multiple distinct characters that remain recognizable even in first person.
With this approach, you implement head bobbing by moving the camera (sometimes even independently of the body animation), the animator will come up with some motion curves for that. That is one think to tweak! Head bobbing, plus some sound effects will convey that the character is calm or agitated, for example.
Many tutorials will have you start with a capsule collider with a camera attached to it ✳cough✳ Unity ✳cough✳, and then animation is attached afterwards. That means that the camera is not attached to the animation, which leads well to this approach.
A drawback of imposing head bobbing this way is that it is hard to get right. In fact, it can even be a bad gaming experience if the animation affects your aim. You can stabilize it by rotating to whatever object the player is aiming at (so that head bobbing does not make the player aim to something else). However, that is one more thing to tweak! Do not stabilize the aim for a character that does not have much experience with weapons, for example.
On the second approach you attach the camera to an animated model, which ideally comes from motion capture. That is what you want if you are going for realism.
The first problem you encounter is that the animation – even if they are from motion capture – will move the head around too much to feel right. In this case you need to start thinking of camera stabilization. The first thing to get right is turning the camera to compensate the rotation of the head (just like we can rotate the eyes to compensate the rotation of the head), in such way that it locks on where the player is aiming. The second part is translation, and that would be done by imposing inverse kinematics on the model.
The state of the art is skeletal animation with a blend-space. Usually a the blend-space is 2D, sometimes 1D, 3D is possible but not common. On it, certain points are mapped to certain animations at animator discretion... and each axis of the blend-space are mapped some variables. For example, you can have horizontal and vertical speed for movement, and different points in the blend-space are for walking, running, walking side ways, walking backwards, etc...
There can then be a weighted blend of these blend-spaces a cross the skeleton. For example one blend-space handles legs for walking and running, and another blend-space handles the arms for aiming.
Finally on top of that inverse kinematics tweaks the positions, for example making sure the foot contact the ground, and that the weapon aims where the players wants to, and – as mentioned above – stabilizing the head.
The alternative to skeletal animation, would be to use key-frame morph target animation. There you animate by picking the next key-frame and interpolating... that is about it.
Inverse kinematic is completely different here. Instead of trying to work out how to move the non existing bones, it is about picking key-frames depending on the surrounding and squash and stretch.
Speaking of squash and stretch, morph target animation is what you want for a cartoon like look, which is hard to get with skeletal animation. Which also means that it is likely that you won't be caring too much about precision of the animation.
Extra: On the Animation of DOOM (2016): Bringing Hell to Life: AI and Full Body Animation in 'DOOM'