I would bet that in almost every case, there is nothing syntactically wrong with the plist file. Apple's functions for loading and saving plist data get a lot of attention and a lot of use. Almost every bug has surely been found and fixed by now.
(Consider that plists are used for all kinds of things, like drag-n-drop and the clipboard, sandbox permissions for launching apps, the user interfaces for every app, and even which icon to display in the Finder. It would be incredible if there was a bug in the plist-writing code which just happened to screw up preference files for some apps, but not any of these other things!)
An app's preference file (plist) is simply storing some of its in-memory data structures on disk. So if the app has a bug that causes something to be set incorrectly, it gets saved.
Often when an app starts misbehaving, you can simply quit it and restart. That resets many parts of it, and may fix the problem. Preference files are reloaded from disk, though, so if the affected part of the app was saved in a persistent preference, restarting the app will have no impact: the bad value will just get loaded again. That's when deleting the preference file can help. It's like restarting the app, but for things that got saved.
These things can happen because programmers assume that the data their app has is correct. If a color can be chosen only by the user clicking on a standard color wheel control, they probably don't do any extra work to verify that it's correct before using it. (In comparison, an app like Safari does a ton of extra work verifying everything, because it loads and runs files straight off the internet.)
The upside is that it's almost always correct, and it's far easier if you assume that internal values are correct. The downside is that if a bad value sneaks in somehow (like the user did something totally unexpected), things can go haywire until everything is reset.