1) I guess it depends on the capability of your sound-engine and the number of objects/collisions you might have at any given time. If you have lots of collisions, the amount of concurrently playing sounds might exceed the limitations of your sound-engine.
It would be a good idea to have notifications for collisions. Whenever your collision-solver detects a collision, it notifies the entities and maybe also your "sound-manager". There you can decide if this new collision should play a sound or (if it's concurrent with another collision of the same type) you don't need to play a sound at all. You should also make sure that a collision fires a notification just once.
2) It's definitely a good idea to queue user-input. Depending on how your input works, you might get multiple user-inputs during one update and you don't want to miss any of these. But this heavily depends on the input library you use (some do input buffering already or allow you to poll on updates etc.).
Generally it's a good idea to have an intermediate layer that handles/normalizes input. Just imagine you want to allow key-remapping or different control-schemes. You don't want to check
if(keyPressed == W_KEY || keyPressed == LEFT_KEY). Rather your input-layer would know about the currently active key-mapping, do the check and return (or broadcast) normalized commands, like