The key is that Apple changed the package structure for applications and neither Disk Utility nor the original installer manifests have any awareness of this change, and so throw out spurious "error" messages.
Let me back off for a moment with some context. Leopard allows for "code signing" with a cryptographic hash to prove that an application has not been altered. The core idea is that malware, upon making unauthorized changes to an application, would be detected. Leopard could -- but does not currently AFAICT -- reduce the affected application's privileges upon detection and so limit any potential harm.
Leopard does recognize and use the signature in the new application firewall. For signed applications, you are NOT asked to approve access to the internet upon updating a signed application. You may notice that unsigned third-party applications however will re-ask for approval upon any update to that applications. As there is no signature, there is no way to prove it is the same application, so the user must manually provide that approval.
I'm not sure how else the signing is used in Leopard, although I expect it to be more integrated in future OS X releases. The iPhone's version of OS X is much stricter, and won't allow installing unsigned applications. In fact, that is the whole idea behind "jailbreak" tools; to allow unsigned applications to be installed and used. And that act increases the attack surface of the iPhone to malware.
Somewhere -- I forgot which point update -- in Leopard's history, Apple restructured the application package (remember that an OS X application is not a single file, but a potentially large collection of files and resources in multiple directories.) There used to a single file with cryptographic fingerprints for every file at the top level of an application's bundle. Newer point version of 10.5.x added a directory just to hold the hashes. For backwards compatibility, Apple added a soft link (alias) in the top level to the new location within a _CodeSignature folder. It would seem Apple is preparing to allow for a more granular set of fingerprints rather than requiring everything being thrown into one large file.
Repairing permissions looks at the original manifest, expects a file called CodeResources, and instead finds the modified structure of a soft link call CodeResources pointing to the file in its new location under the _CodeSignature directory. This change is responsible for the error message (the "l" is the new link) in every application or code-containing bundle (including internet plugins) that has been updated to the new directory structure. It is an error only in the sense that Disk Utility is not aware of the equivalence between the older and newer bundle structure. One can presume that an install of Snow Leopard would include installer manifests reflecting the new structure and hence would not indicate these spurious errors.
To that end, I'm not sure it is even worth worrying about. If one has a problem due to permissions, and repairing permissions fixes it, great. If not, and I believe this business of repairing permissions has been elevated to the point of obsessiveness, also great. In any case, those "error" messages are certainly NOT indications of anything being broken or damaged.
