Moreover I think the whole "let the user decide" attitude is just a lame excuse developers hide behind when they can't figure out a decent UX. (It's no wonder design-by-committee software like we see on desktop Linux has so many UI options... Nobody can come up with anything people can agree on so "make it a checkbox so the user can decide" becomes the solution.)
Unsolicited sound is a horrible idea on any platform, it's a good thing that iOS only allows it when there's a touch event somewhere in the call stack. Dialogs would only worsen the problem; disallowing it altogether is the only sane solution.
Developers do lean on users too much to solve UX problems, but I still maintain that giving users a choice here would have been the better alternative. Access to device sensors are almost always behind some kind of permissions dialog on major platforms. Personally I like web/iOS model best, it prompts me when an app/site wants to use my microphone, gps, camera, etc, and then remembers the choice I've made. Making potentially invasive or offensive application behaviour completely transparent to the user is a good user experience in my book, and it discourages developers from using those sensors unless they actually need them. Although I can concede that getting permission for unsolicited access to the phones speaker might be going to far from the small sample size here, and I am just as annoyed at the recent auto playing video trend on the web as anyone else.
Unsolicited sound is pretty important for games, and increasingly the web is becoming a pretty good platform for them. I wrote a little game a while back and I worked around the sound issue in Safari by initializing my sounds (just a few) on the users first tap, not a back breaking workaround or anything, but still annoying that I had to work around Safari. Here's the thing though, if I hadn't been testing on iOS a critical (the sound actually was) part of my game would have been broken on iOS. I guess I'm just grumpy about that... :-/
