Much of lore is simple facts. For example, in VB6, it is lore that you must test both BOF and EOF to ensure that you have an empty recordset (the set of records retrieved from a query). The VB6 documentation would lead you to believe that on a freshly-retrieved recordset, you only need to test EOF to find out whether the recordset is empty. What helps to make this fact a piece of lore is that this works *most of the time*. However, there are times when testing only EOF will lead your code to try and work with non-existent records in the recordset. Another example (for my taste) is the Perl5 lvalue sub, which from the docs you would think that it is a dandy way to implement data validation. Not so, my friend you cannot examine an assignment value on the way in, nor can you verify the return value on the way out. (This is fixed in Perl6.)
Undocumented program feature facts are a rich source of lore, so much so that graphical features have their own nickname Easter Eggs. However, I suspect that non-graphical hidden program features, like secret administrator passwords, cryptic database schemas, and clandestine command-line switches, form the bulk of undocumented program features.
Another origin of more lore-facts is performance issues, like BLOBs and DB fragmentation. If I recall correctly, it has been more than 10 years since database vendors added support for BLOBs to relational databases, but relational database BLOBs still suffer from performance problems. The tingling of my architect sense tells me to look at what is different about BLOBs compared to other DB datatypes. The difference is that BLOBs do not fit on a database page, while other datatypes do fit on a page. Databases are precisely tuned for high speed via sophisticated page-caching mechanisms. Many table schemas lead to entire rows that will fit within one page. BLOBs break this rule almost by definition, as a BLOB is expected to span multiple database pages. This makes a BLOB much more like a file in a filesystem than a field in a database row, which may account for the number of systems that I have seen out in the field where the BLOB-like data is held separately in a filesystem, with some kind of link to the BLOB data as a field in the database. From what I have seen (or failed to see), reading the DB vendor documentation would lead you to think that you should always use in-DB BLOBs for large pieces of data, while developers seem to continue placing their BLOB data outside of the DB with only a link to the BLOB data inside the DB. This is a prime example of lore (IMHO).