1. It's a compositing manager! That's for graphics. When did sound enter into the picture?! Your desktop / session manager handles that, or even individual apps -- right?
2. Why (just) ALSA? If you're too timid to write a PulseAudio client, at least use OpenAL -- that basically allows you to avoid the problem of having users debate the merits of various sound APIs to you, because chances are fairly good (especially now with OpenAL-soft looking up) that whatever sound backend your users are using, OpenAL has a configuration that works for them. Plus, you could work 3d positional sounds into it, using OpenAL's API, so you can hear sounds coming from various areas on the surface of your desktop cube. That would be cool, but still -- it's not the job of the compositing manager, I think.
The unfortunate part about compiz supporting sound is that you end up adding to the overlap between various parts of the desktop. If every part of the desktop tries to encroach a little outside of its core territory, you end up with chaos: two or more different programs (mutually unaware of what the other is doing) trying to perform similar or identical functions. Not only is this frustrating for the user, but it can result in incorrect functionality, such as two sounds playing from two different programs when an event occurs.
I think compiz should expose a lightweight external interface that sends position data and event metadata whenever an event occurs that would demand a sound effect. You could have a thread in the desktop or session manager do blocking reads on a UNIX pipe, and have compiz write to it with a pre-determined data structure to define something like, "event of type W<string> at (X<int>,Y<int>) on desktop surface #Z<int>". That's just how it would be pretty-printed; the actual data format could just be a serialized representation of a struct.
By sending plain ol' data to the desktop and allowing the desktop to decide what to do with the data (visual cues? sound? logging? other uses?), it would be much more flexible than implementing sounds in compiz.
I haven't checked, but if compiz already has an external interface of a similar design that would effectively trigger whenever the desired "compiz sound effects" would occur, then the sound effects thing is already completely redundant.