I assume you're talking about a project in a programming environment and not any game maker type of tools?

It is easy to be tempted to use a full out physics engine for a platformer but that's usually a bad idea. Too many unnecessary computations for what really is simple stuff. So I'd advise to stay away from libraries for this purpose.

The two most common methods I know of are tile based maps and sprite based maps. With tile based maps you have solid or non-solid tiles. For slopes you can decide on a fixed set of angles to use for the slopes and hardcode the behavior (e.g. sliding). Collision detection/avoidance tends to be quite simple with tiles.

Sprite based maps offer more flexibility but require more work. The geometry can take on many different shapes and usually collision shapes will need to be drawn to represent the graphical shapes. And by nature, these require more computation.

I don't really see the problem with representing a humanoid with a rectangle. Why would the feet or head require hacks? As long as the bounding box encompasses the sprite during all the frames of the animation it shouldn't have any problems. Shrinking the collision box for crouch and rolls is not really a hack but something you'll have to do anyway. You know the size of the sprite so you could easily assign different collision boxes to different states for the player, e.g. standing, crouched, etc.

I tend to use tile based methods whenever I can since it drastically simplifies work flow. Players usually don't know how things work in the background and as long as the game is fun to play, they won't stop to ask the question either. I can imagine that as a programmer you'd want to implement systems as "correctly" as possible but in games (specifically) it's not really worth it when you can get as good, or maybe even better, results by "faking" it.

The state of the art in collision algorithms is vertlet integration. If you're interested in highly interactive environments, a robust physics engine is important, otherwise you're forced to hard code all of the ways the player can affect the game. That isn't to say that physics (even 2d) is an easy problem.

To address your specific concerns:

Bounding Boxes

You can construct objects from a hierarchy of smaller elements. This will prevent the "standing on air" problem you can get when a rectangular bounding box is fit around a round object.

Advanced Behaviors

A robust physics engine will operate based on material properties and applied forces. This makes certain behaviors difficult to implement from a purely physical standpoint. The way I deal with it is to first separate the character animation from the collision geometry. Then, use collision information and user input to choose a proper behavior. That behavior will consist of a particular animation and the application of external forces onto the collision geometry. For example, say I've detected that the player's geometry is hitting something on the right side. I can detect that "something" is actually a ladder object. Also, I know that the player is pressing the up button. This means I will initiate the climbing animation and apply a force to the right (to keep the player on the ladder) and up (to make the player go up the ladder). To implement everything physically is overkill.

I should note that in a vertlet integration engine, displacing vertices is equivalent to applying forces. So to apply the forces described above, it would be sufficient to translate the player's bounding box so it's flush with the ladder and displace the geometry up, to apply an upward force. The engine will change the player's velocity as if a force had moved it.

Dynamic Environments

From a physics engine standpoint, if you use vertlet integration, there's no reason the environment should be handled any differently than the player. You can move vertices in either and the system will react according to the constraints you've implemented. If you're talking about AI, then yes, it's much more difficult to deal with arbitrarily changing terrain. You have no choice but to recalculate paths any time the terrain morphs.

If you can't get away with using a bounding box and it has to be pixel perfect, then I read about (but can't remember where) having sprites with a transparent surround, and testing the colour of the individual pixels, at the boundary of the sprite to see if the background object intersects. I suspect that this is impractical to do in the vast majority of cases however, as your game will probably grind to a halt whilst you test all of those pixel colours.