You can reuse profiles among multiple groups (and reuse subprofiles within the profile heirarchy a well), and this relieves the pressure on keeping the number of groups low. Try not to let the idea of "a tree with ap groups at the root" weigh too heavily on your planning.
Really it boils down to 1) that your total number of profiles is not very high, so changes to parameters are not tedious 2) you can easily hold in your head which profiles will affect which APs and 3) when you just want defaults in a particular type of profile, decide whether you also want those profiles to pick up any changes to the defaults that may occur during upgrades. The answer to that last one may vary from type to type -- if you do not want that to happen, create a profile as a clone of the default to insulate it from changes.
Don't be afraid to use a few or even quite a few "ap-name" overrides here and there if doing so simplifies your profiles/groups.
Note that including the type of the profile in the profile name is not needed since all the commands to alter or apply a profile contain a profile type, and think of the names of profiles from the perspective of what you will need when you are doing text searches on the config file or via the UI. (When doing work directly at the CLI searching is less than awesome because the running config puts quotes in where they are not needed, so including the type in the name does help in that one situation, bur overall it makes things longwinded.)
In many other configs I've seen, people do groups by building. It is good to do this for a few buildings where you will be doing production testing of new settings before rolling them out systemwide. In general my opinion is that it is better to split things up primarly by the environment the AP is serving and by the AP model, because those are the factors mot likely to require different settings. Note that groups are one of the ways reports are easily split up in Airwave, but so is AP name, so if your APs are named by building you can still manage to get some reports by building even if you do not group them that way, and then use Airwave folders orthaginally to buildings as well.