What special powers does ashmem have?

Ashmem allows processes which are not related by ancestry to share memory maps by name, which are cleaned up automatically.

Plain old anonymous mmaps and System V shared memory lack some of these requirements.

System V shared memory segments stick around when no longer referenced by running programs (which is sometimes a feature, sometimes a nuisance).

Anonymous shared mmaps can be passed from a parent to child processes, which is inflexible since sometimes you want processes not related that way to share memory.

Can someone explain why ashmem was created?

David Turner (a regular on Android NDK) answered this in Why was bionic/libc/include/sys/shm.h removed?:

... System V IPCs have been removed for cupcake. See bionic/libc/docs/SYSV-IPC.TXT for details.

In brief, System V IPCs are leaky by design and do not play well in Android's runtime environment where killing processes to make room for other ones is just normal and very common. The end result is that any code that relies on these IPCs could end up filling up the kernel's internal table of SysV IPC keys, something that can only safely be resolved by a reboot.

We want to provide alternative mechanism in the future that don't have the same problems. One thing we provide at the moment is ashmem, which was designed specifically for Android to avoid that kind of problem (though it's not as well documented as it should). We probably need something similar for semaphores and/or message queues.