Does this design satisfy 3NF, and can any improvements be made

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.

1. 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.

2. 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.

Yes, this conforms to 3NF as far as I can see.

Basically 3NF is met when all non-key values (assuming natural keys here) in relations are non-transitively functionally dependent on the key. Surrogate keys don't count for this analysis since category.name is not functionally dependent on category.category_id. In fact, category.name is probably your natural key and category.category_id is functionally dependent on it for purposes of this analysis (because it is in essence a join dependency stand-in or surrogate for your natural key). Going through your tables here I do not spot any cases where this is violated.

The one obvious change that this suggests is what was mentioned in the comments by others, to move customer_id into hire and out of hire_equipment (if third party loans of equipment are supported you probably want customer_id in both places though).