Why can't we have counting mutexes?
Because what you've described as a "counting mutex" is a semaphore.

A semaphore has a common resource with a limited number of identical copies; think of a library with 5 copies of a book. Users can go to the library and checkout a copy, and it doesn't matter which copy they get because they're all the same. However, only 5 users can have that book checked out at any one time because there are only 5 copies.

A mutex on the other hand is when you want "mutual exclusion", i.e. a user has exclusive ownership of a resource. Each resource is unique. So say now there is a library which owns only one copy of 5 different books. Each book could have a mutex associated with them because it matters which book you check out, and only one user can checkout a book at a time.

edit:

I suspect the Keil RTX mutex implements this by acquiring a primitive mutex, then once acquired the first thing is to set an ID of who "owns" that mutex. In this case, the library interface prevents users from releasing a mutex they don't own.

Implementing this for a semaphore is trickier, but should be doable. One way is to implement this might be to after acquiring a copy from the primitive semaphore, add your ID to an empty slot in a fixed-size list of what has been checked out. Then to check-back in, check this list for the task ID (optimization: store this spot local to the task so check-in is O(1)), and if you find it remove it from the list. Finally, release the primitive semaphore. Again, this would be a library interface design choice, not something inherent to a semaphore.

The difference now is that checkout is O(n) in the number of copies; this is a huge difference from O(1) for everything before. I don't think libraries want to burden all users with this unnecessary overhead, so most don't implement semaphores like this.