All of this is in my opinion, but here's my explanation why it should be that way (leaving all role capabilities that aren't Allow as Inherit, and not using Prevent at all).
This doesn't make it any less secure - the default is to not allow something, so if a role doesn't allow it, then it won't be allowed, regardless of whether Prevent is set.
So, this doesn't make any difference when you have only a single role. But when you have two roles it causes unexpected behaviour. For example if you are an admin but also a student/teacher on a course, you would expect to keep admin privileges within that course. Because the student/teacher role sets everything it doesn't do to Prevent, in fact within that course you don't have any admin privileges.
In the role definitions, the only commonly-needed options are Inherit and Allow. (It might be desirable to hide the other options behind an 'Advanced' expand button.) Prohibit is useful only when creating 'banned' roles. Prevent, on the other hand, is rarely useful on this screen and would be used only in roles that are intended to be 'secondary' (applied in addition to existing roles) since prevent stops you doing things that you are allowed to do elsewhere - and if you don't have any other roles then you can't possibly have been allowed to do anything else.
For another example, supposing we want to allow a particular student to moderate all forums on the course, when students don't normally have the capabilities for that. No problem right? We just create a 'moderator' role and set it to Allow those capabilities, then give it to the student on the course. But no! Because the Student role has a Prevent, that cancels out the Allow from the moderator role. So the moderator role will only work when applied in individual forums, which is an unnecessary limitation.
Prevent is of course highly useful in the module overrides screens! But it shouldn't be set for any capabilities in any of the default roles.
PS There might be cases when you genuinely want to reduce the powers of a particular admin or a particular teacher within a context. For those more unusual cases, you would indeed need to create a role with 'prevent' in [since the 'unassign' proposal, that would allow user roles to be disregarded in certain contexts, wasn't included in the system].
I've filed MDL-6907 to track it.
Just a quick note... This is a very important point. We just spent three days troubleshooting the roles config for our newly upgraded 1.7 installation. We were using prevent in the guest role for capabilities we don't want guests to do, which seems intuitive btw... but causes major problems if you try to have another higher level role allow that capability with the override matrix.
The fix for us was to change the prevents to inherits (in the guest role).
If I get a chance, I'll update the docs/wiki...