It is partly for historical reasons. When I first began the mojoPortal project in 2004 I first implemented support for MySql using the MyIsam table type which does not support foreign keys, so at the time I made the decision that we would not use cascading deletes or that kind of thing and application logic would be used to delete child rows rather than cascade deletes based on foreign keys. For consistency I've followed the same approach in all the data layers. A few years ago we changed from MyIsam to Innodb tables in MySql which do support foreign keys but I've only used them in a few places since then and still we use application logic for managing child rows and data integrity so often we use just normal indexes rather than foreign keys. I also find that in general I'd rather risk a few orphan rows than have cascading deletes that wipe out all related data or errors due to foreign key constraints. If I delete a user it doesn't mean I want to delete orders that user may have made in webstore or posts he made in the forums for example, I'd rather have an orphan order than have it deleted.

Also there are many situations where we join against common tables based on guids, like I can store ratings for Html or blogs or pages or users or products in the mp_ContentRating table because each thing can retrieve its ratings based on an indexed contentguid column in mp_Ratings that may come from/relate to the mp_Html, mp_Blog, and other tables. If I was stuck in the foreign key mentality, then when I first implemented ratings for the Html feature I would have had a foreign key on the html table, but there can only be one foreign key table for a given column so then I would need separate rating tables for each feature.

Keep in mind that we support 6 different database platforms all with different capabilities and for web apps there has been a movement in the last few years towards NoSql non-relational storage for performance. Even with a db platform that supports full relationships and normalization it also impacts performance. So I do not consider it a bug, it is a design decision. What big or small problem does it create if somehow application logic fails to delete a child row and leaves an orphan? In the 9 years that I have been supporting mojoPortal it has never caused any real problems that I know of. Not everyone agrees that foreign keys are always needed or that databases should always be normalized, though of course some people do think that. Reporting and data wharehouse type apps are usually the opposite of normalized for performance reasons and web apps in my opinion are kind of a middle ground where performance can be much better without them and that is more important than avoiding any possibility for an orphaned row. Myself I see good reasons for using them in many cases but I also see good pragmatic reasons for deciding against in other cases.

You are free to implement whatever strategy you want in developing your own custom features. If you consider it a bug that we don't have foreign keys everywhere that is up to you as well, but I do not consider it as such.