ASA and PIX obfuscate keys and passwords when issuing 'show running-config', unlike the other OSes. I guess this is an intentional feature but the effect is that many configuration management utilities that retrieve the config interactively don't have a copy of the config you could actually restore to a device.
Workaround: 'more system:running-config', or copy the config off the box with FTP/TFTP etc. Cisco say.
Benefits: now you can actually keep a backup of your device configuration that you could restore from in the event of catastrophe.
Down-side: you lose the 'last modified by' line in the config which screws up some configuration change auditing tools.

Pager length needs to be set differently on this platform. Improperly configured configuration management utilities that retrieve the config interactively are often broken by this subtlety and so choke on 'show running-config' after blindly running 'terminal length 0' expecting the pager to be disabled.
Workaround: command.
Benefits: none.
Down-side: none.

Optical transceiver diagnostics (which the CLI output is quick to remind you 'are not reliable') can be seen to display low power warning indicators (--) next to power measurement values when the value itself is clearly inside normal operating thresholds which it prints in the same output. Run the same command a second time (literally: up, enter) and hey presto! The alarm is gone.
Workaround: run 'show interface EthX/Y transceiver detail' twice before reading the output?!
Benefits: none.
Down-side: annoying

The output of some QoS related commands gives buffers numbered from 0, and other QoS related commands show buffers numbered from 1.
Workaround: none.
Benefits: N/A.
Down-side: N/A.

Amongst other similar commands, these 2 variants work happily on most versions of IOS, but depending on the platform your config may not actually reflect what you typed, just like the parser won't suggest both variants on the same platform.
Workaround: N/A.
Benefits: N/A.
Down-side: N/A.

Every person who works with IOS should know about the 'do' command to save themselves exiting and re-entering 'conf t' when needing the output of a 'show' command to determine what the next piece of configuration should be. However, Cisco once again manage to do something inconsistent and wacky. If you use upper-case characters ANYWHERE (OK, so there are only 2 places, but this accounts for 3 of the 4 permutations) in the word while you are in a nested config block (such as 'router x y' or 'interface Ethernet1'), the parser deems it appropriate to exit this nest for you. From (config-if) to (config) by just capitalising one or both characters in the word 'do' (situation where this might happen? 'conf t', 'int Eth1', 'descr I_USED_CAPS_LOCK (MAIN VLAN)', 'DO SHO VLAN | INC MAIN', 'switchport access vlan 1'... this last command is now invalid because it's unintentionally at (config) instead of (config-if). D'oh!)
Workaround: Don't use caps-lock or accidentally capitalise 'do'?.
Benefits: I guess this could be useful if you know about it and want to save yourself typing 'exit' from a piece of nested config such as router or interface configurations.
Down-side: Unintended exiting of a mode you wanted to stay in, potentially leading to accidental configuration of something globally, or more likely an error for invalid command at the current configuration level which is a real PITA if it's copy/pasted config.
Example:

The 3750, for reasons I cannot fathom (but are documented) differs from most of the other Catalyst platform products by using 'boot system bootflash:file.bin' for example, rather than 'boot system flash bootflash:file.bin'. Just one to be aware of, because it's caught me out on late-night fixing sprees.
Workaround: N/A.
Benefits: N/A.
Down-side: N/A.

CBS30X0 software version 12.2(40)SE2 disagrees between the CLI parser and what it generates in the config. The parser requires 'errdisable flap-setting cause link-flap max-flap' to be executed, and it dumps 'errdisable flap-setting cause link-flap flap-count' into the config. The latter isn't recognised as a valid command, and so every time the config is re-read (on boot) it is rejected and not coppied to running-config.
Workaround: Upgrade? Re-apply the 'correct' version of the command every reboot?
Benefits: None.
Down-side: Config requires manual fixing every time the switch is booted.
Example:

You might expect that the output of the running configuration was something fairly trivial, but it turns out Cisco have managed to break it. This bizarre omission of configuration (I've seen it drop 'no shutdown' and 'description' commands, but there may be others affected) from L3 interfaces (SVIs, or 'interface VlanX') caught me out twice: once when reviewing SVI configuration between two HSRP peer 5548UPs and observing odd discrepancies that disappeared before my very eyes, and again when my configuration management server backed up the config with a 'show run', processed the diff and alerted us to the apparent removal of 'no shutdown' and 'description' commands on all the SVIs. The next change detected had these reinstated. Odd!
Workaround: None.
Benefits: None.
Down-side: annoying, potentially dangerous if relied upon for backups captured from a VTY 'interactively'.