There are good answers here. I had to figure it out for myself on the project I'm on, but came to the same conclusions as the Sucker Punch guys (and I had thought I came up with something novel. Baww :( ).
I find it useful to consider your entire first person 360x180 degree "panorama" as an "acceleration field". All valid targets create gravity wells which bend the player's input (only subtley) such that macro motion (turning to face targets) feels as though it's a "greased" path. However, this is not affecting the crosshair all of the time - only when the player's turn delta is pointed with the slope of the well (as it were). That's really key though - you're only giving this extra turn speed when the player is turning roughly toward a target. That's about the only inference you can make from the player's input.
Much more, and you get too much of a noticeable "ouija effect". You want the exact opposite of ouija: Where a ouija board is moving unintelligently due to a user, without their conscious knowledge, you want a player's crosshair to move in an intelligent way without the user realizing that it's NOT purely their input. It really is a bit of a magic trick.
Use the dot product of the player's pitch/yaw turning delta vs. the pitch/yaw delta from the crosshair to each target. Clamp the value between 0 and max speed (so you ignore the input while pushing away from the target), then use a function of distance as a falloff modifier.
I found that increasing this "macro movement" bonus when the crosshair vs. target angular delta is large (i.e. when an enemy is behind you) really helps with the classic console controller problem of not being able to turn-to-face quick enough. In terms of "targetting choices", if you're being attacked from behind, and there's no targets infront of you, that panorama ahead of you is "dead space", and you might as well give the player the ability to fly across it at great speed with their cursor. And if there ARE targets ahead, well, they're probably higher in the player's mind and due to dampening/sticky aim, aren't unduely affected by the weak macro force.
There's not much need for you to dampen sensitivity when the player tries to turn away
from an object (this will result in a feeling of trying to "escape" a target's orbit). Dampening is used more for precision aiming, and also to stop players' aim overshooting when moving from macro to micro precision - It's the darnest thing: players (especially novices) have a tendancy to only use the extremes of a stick's deflection, so you have to do a lot of finessing for them.
Sticky aim is a relative movement compensator. Watch the difference between the angle to your target (from the camera, not from the entity origin), this frame, and last frame. See how closely you are aiming to the target. To avoid the ouija effect when there is no user input, check both sticks' deflection: See if you have physically moved (left stick actuation) OR if there is active aiming "with" the direction of the target. Add the yaw/pitch delta step * aim closeness * Max( move.length , aim.length ) for rudimentary sticky aim.
Where the issue of target confusion comes in (i.e. a target strafes across your view while you were aiming at something behind, "stealing" your focus), simply keep track of your targets, and "heat" a single one while it is being actively aimed at. Then, multiply the dampening and sticky components by this heat parameter so that unheated targets get ignored. If the player WANTS the help on that other target, they'll manually aim toward it, and very quickly, that becomes the most prominently heated target while the previous one is forgotten.
We also create "phantom" aim assitance targets to help you turn away from uninteresting things (i.e. facing a wall - no need to hang around looking at a close up blank surface if it's not usefully interactive), but it's probably more than I can talk about - you can apply this stuff to anything that's interesting for the player to point at, be it explosive barrels, interactive objects (bioshock uses dampening when aiming over interactable objects at close range... but doesn't do sticky aim on them, I don't think). Once you realize that this is all just to compliment the core concept of aiming, you realize it's not just about aiming shots, but a general useability improvement which feeds into any mechanics reliant on aiming. And in an FPS, really, movement and aiming are the fundamental core concepts you need to nail before developing onward.
The improtant thing with all this is tuning. Takes a long time to just get right, and to deal with target interference, and issues with targets being so close range that their "targetting zones" swamp the player's panorama, slowing 60 degrees of rotation down to a crawl.
Oh man, I should get to bed. Sorry if some of the maths is not to clear. It's really late, but I was excited reading this post.