Because a parent POM should be nothing but a POM. By the way, I think you are confusing two different hierarchy mechanisms.
One is the module/submodule hierarchy. This is where there is a master POM which invokes submodule POMs to build the individual artifacts of a larger project. The master POM can be a POM package, or any other type of package. For example, it could be an ear, or even a jar (you could use the assembly plugin to create a runnable jar). Though usually it is best to have the master POM be a POM package, and have the last submodule be the "packager".
The other hierarchy is the parent/child hierarchy. In this case the parent POM is always packaged as POM. Also, the parent contains declarations common to all of its children. For example, I have a parent POM for building JArs that has all of my common settings for all JAR files. Then each time I need a new project that defines a JAR, I reference the parent POM and get all of that configuration information automatically.
There is no rule that says that a master POM must be a parent POM for the submodules. And I recommend against doing that. I have been telling my co-workers this for years and each time they don't listen to me, and make the master POM also a parent POM, they run into problems.