Planning simple CMS: How much relation?
Once you start stepping into areas like hierarchies, you probably want to know your RDBMS to some extent.  If your RDBMS supports recursive queries natively your hierarchies will look very different then if each iteration is a round trip to the db.

This being said there are a few warnings that come to my mind looking at your schema.  I believe these are likely to impact both performance and data integrity.


The separate parents table strikes me as somewhat dangerous.  What are the rules for parents and children?  Can you have blog -> menu_item -> blog -> comment -> menu_item?  This first creates the possibility of problems that may be difficult to track down, but also consider that if the rules are based on smaller tables, actually enforcing the rules becomes possible  If your menu items are broken off, a caching layer becomes a possibility. Same with other things that are less frequently changed, and the amount of effort to generate the menu on the part of the db will be reduced.
I actually think your second model, if things like menu items, etc. are broken off is likely to be both more scalable and faster.  I would still suggest breaking apart comments and blog posts, and tracking the relationships there more closely.   If you are worried about scalability and your site has 10000 blog posts and 1000000 comments, being able to filter the comments also by the attached blog post is likely to mean you can get to use better indexes at least on some db's.


I am reminded of the phrase "premature optimization is the root of all evil."  Design a good db schema first and then worry about speed and scalability.