There's several issues with it - none are insurmountable, but all require you to be wary.
Firstly, there's the fact that you need to handle control in a central part of the code (so remaps are handled universally) - it's possible for an arbitrary routine to poll the pad directly, and you need to avoid this. Which is easy to do - provided you plan the infrastructure to do so in advance. Unfortunately, if you're trying to prototype something quickly, that can fall by the wayside, and it's a much harder thing to put in retroactively.
Secondly, there's the fact that there was - and I assume there still are - requirements for *menus* on console titles to behave consistently across all platforms. On Xbox, it's required for A to be 'accept' and B to be 'cancel', for instance. So you have to handle menu mappings independently of the game control mappings, another place where it's possible to make mistakes.
Thirdly, remapping controls is a powerful tool, and one of the problems with powerful tools is that people will screw up using it. We have to make it idiot-proof. We can't *let* the player remap jump and duck to the same button, for instance, no matter how much we want to. The game I wrote control remap routines for - the original Sniper Elite - suffered a lot, too, from the fact that the control design - made with a PC-centric outlook - used more controls than the pad actually had, meaning a large number of controls were of the form "Tap A to do something, hold A to do something else". We just about got around that by remapping *all* of the controls on a single button in one go, but I was never particularly satisfied with that result.
It's very possible to do - I mean, I have *done* it! - but it can require a lot of iteration and testing to do it right, and that time may be better allocated elsewhere.
