I don't know what would be going through the mind of someone that thinks that Enums should be modeled by using separate tables (i.e. one table for males, one for females; modeling the enum Gender = Male | Female), so I am not even going to talk about those. I am going to jump right to a model that won't make people cry.
I didn't see anywhere in the original article that models "gender = male | female" as two additional tables. There is a schema variant that uses a single additional table "genders", with foreign keys pointing into that table from the "humans" table. That seems like quite a plausible choice for modeling an enum in a normalized fashion, and it provides a clean way to handle when the set of enum choices changes (that is, new choices can be added trivially, and data integrity is automatically checked when options are removed). It's not the most efficient or concise representation, of course, but those are not the only criteria when choosing a data model.
I didn't see anywhere in the original article that models "gender = male | female" as two additional tables. There is a schema variant that uses a single additional table "genders", with foreign keys pointing into that table from the "humans" table. That seems like quite a plausible choice for modeling an enum in a normalized fashion, and it provides a clean way to handle when the set of enum choices changes (that is, new choices can be added trivially, and data integrity is automatically checked when options are removed). It's not the most efficient or concise representation, of course, but those are not the only criteria when choosing a data model.