I'll bite

[very long post follows]
I don't think its too much of an assumption to assume that queries involving address/profile are less frequent than the login user table. The o.p's comments on the adress fields early in this thread made it apparent that its not used often and isn't even required data. On most sites how often do you view your own or another member's profile compared to how often you view "regular" content. Even most forums that inject avatars,sigs etc do so at post time not at view time; those that's i've inspected that inject at view time have moved those fields to the signon/user table.
Re: abilities of RDBMS, I'm clueless when it comes to MySQL, but most provide one or more of these tools (OK I just checked mysql's manual and apparently it doesn't offer any of these) If they can't, you can always do it in application logic. If I were a heavy user of MySQL, I'ld probably write some code to autogenerate my "helper cascade queries" as part of my database library. Yes a design should be relatively RDBMS independant, but neither MySQL nor PostGreSQL nor MS SQL nor even Oracle(to my knowledge) is even fully SQL 92 compliant so you're always going to have to use some work arounds. If MySQL doesn't support some feature, you should at least understand why some other system included it. If its functionality sounds useful, figure out how to mimic it.
Re: Normalization. I don't think I've ever seen a large transactional database that was entirely in 3NF (or BCNF, 4NF, or 5NF). One guilty feld is almost always storing zip, city, state in the address table along with streets. zip fully determines city & state. so it should be its own table. This is one place however where efficiency tells you that as you almost never use the street address without the city/state/zip that they should jsut stay together. Database design include normalization to help manage complexity, but must be balanced by efficiency. Normalization tells you nothing about what indices to create for example.
Yes I'll agree that it doesn't give any great benefit, but it may give a small one. It does make the application more complex, but more complex does not always equal more difficult to maintain. And in my mind the best scenario to learn db design is the one you're currently pscyhed for and actively working on. I believe he has a working prototype or similar running on this database, so he can fiddle with different database setups and change a few queries and see how he likes it. For a different project he'd need to design and write all the surrounding code. Sometimes adding a little bit of complexity at one level, simplifies the design at others tremendously.
We've only seen a snippet of his database schema. Regardless of how he decides to go with this table, this debate should help with other parts of his schema.
OK I just finished reading some more about MySQL, so I have a somewhat greater understanding of the framework most PHP users work within. I'm not sure how I would vary my advice now, but I think I agree more with my "debate opponent" than before, if MySQL is the DB used. However, many of the features I mentioned are planned for relatively soon releases (measuring soon by the projected version number, didn't dig to see if they have any target date). I think I can understand equating DB design with Normalization in the realm of MySQL. MySQL is a wonderful tool, but if you want to understand more about DB design you need to know what other systems offer that MySQL doesn't (and what MySQL offers that others don't), then if a missing feature solves a specific problem maybe it provides you with insight on how to implement a similar feature in application logic.