Do you have any idea why?
In my opinion it's beacause you can manipulate the areas' tree, and therefore there is no logic in putting them in hierarchial folders anyway..
Do you know if there's a way to change this behaviour?

I agree that there's no sense in putting them in heirarchal folders, but it seems a bit arbitrary to cap the number of pages at 20 and then start a different naming convention. Why not just go all the way with their naming scheme? I don't know.

From what I understand, there isn't an obvious way to change this behavior.

It is my feeling this is done to distribute created areas over folders (they are not pages, they are sites), because otherwise tools like FrontPage would display a very long list of areas in a folder. I can't think of any other reason. If you would like to hove nice "entry point" to a deep linked area Microsoft proposes to use hostheaders to create nice names like http://myarea.domain.net

Areas aren't really "pages" they are in fact logical containers. Every area is backed by a WSS SPWeb object. This SPWeb object is used for storage. Remember that SPS is built on top of WSS.

Areas and SPWeb are not 1:1. SPS buckets the backing SPWeb for areas e.g. you may have 20 areas sharing the same WSS SPWeb. This is done for scalablity and performance reasons. Basically SPS buckets like this to ensure that no one backing SPWeb contains too much data because this will cause WSS performance to suffer.

When you see a URL like http://mysite/c16/myarea">http://mysite/c16/myarea "c16" is in fact the backing SPWeb.

If you can check this out yourself by trying to navigate to this SPWeb by going to http://mysite/c16/. You'll get access denied and a WSS error page.