I use OpenGL::Simple. I've been very happy with it so far, although I haven't tried to do anything very complicated. (Although I mix it in with some pretty complicated OpenGL calls made directly from C++ code, and that works fine.)

I also am doing what you say doesn't work very well -- I have a large C++ application with an embedded perl interpreter, and I use both OpenGL::Simple and Inline::CPP (extensively) to provide the glue between perl and C/C++. And I use my own event loop. For the embedded interpreter, I just had to give up on any notion of modularity and allow it to use all of its global variables and related nastiness. The result seems to work fine. I don't make heavy use of callbacks, but I do use them.

That said, it's quite a big chunk to get working nicely together, and it's busywork that has little to do with the main part of writing a game. It would be nice to have a prefabricated framework with all these things mixed in. (I didn't mind doing it, because I was getting paid for it. And I was really just adding scripting to an existing framework. Can't release it as open source, sorry.)

I can't really address the OP's question. For sound, I use SDL_mixer, but I only call it from within C++. In practice, I often trigger sounds via perl scripts, but they're just manipulating a sound node written in C++, not directly triggering sound playing. Again, probably too much framework for a straightforward game. Although an Inline::C wrapper to call SDL_mixer functions would be pretty darn easy to write.

Inline::C is awesome. Just thought I should mention that.