I understand where you're coming from on this. Lots of constructor parameters is a sign that a class has a lot of external dependencies, which often means it's trying to do too much. It's what they call a "code smell."
Unfortunately, making them a singleton/static/otherwise-globally-accessible doesn't solve the root problem (it just masks it), and runs the risk of creating additional problems. I don't know if you've heard people talk about how bad global variables are, but all of these are only slightly less bad than that.
Among other things, having them be globally available stops you from supplying alternate implementations for these things, and the dependency becomes more tightly coupled. Imagine if you create an alternate input library. (Not sure what it would do, but for the sake of this discussion, let's say a different input library for touch, keyboard/mouse, and game pads.) In your first version, it's pretty easy to just pass in a derived class, and have OptionsScreen just use it without knowing the difference. If it looks it up internally, as some sort of static lookup, you have to go to OptionsScreen and probably half a dozen other screens to make the change.
Likewise, with all of these, you could pass in a "stub" or "mock" implementation to allow yourself to write unit tests for these. Perhaps ones that don't require going to the file system to look up real sounds. I know not everybody does unit tests, so this particular argument is maybe less meaningful to those who don't. (I'm not perfect at it myself, though I've gotten much better over the last few months, even on my personal game dev and other personal projects.)
Basically, whether you know it or not, you're following the Dependency Inversion principle, which is the 'D' in SOLID. It's a great principle that will make your life much simpler in the long haul.
Another thing I want to add here is that 5 doesn't seem crazy. Obviously, fewer is better, but on a large project, we often get some projects with 8 or 10. We don't like it, and we try to find ways to refactor the system so it doesn't have so many dependencies, but definitely, 5 isn't "shockingly bad" or anything.
There are two ways that I think you can go about trying to reduce the number of dependencies here. First of all, can you combine some of them together, if they're closely related. For example, maybe SoundManager and MusicManager are maybe so closely related that they're the same thing. Maybe not. (I personally like the separation.) Another possibility might be combining the font and the content manager. Do you really need to supply the font, if you can just look it up through the content manager? On the other hand, perhaps all of the needed content should be passed in, and you shouldn't need content manager as a dependency here at all. That could easily lead to an explosion of parameters, which you're trying to avoid, but maybe they all get packaged up into a "resource locator" that has a property for every piece of content that OptionsScreen needs. I guess my point here is, why do you pass some content in directly, and then also pass in the content manager? It's an inconsistency (but probably not a bad one).
Quite honestly, I'm not sure I'd change anything (or much) with respect to the above point.
The second thing you could look at, and probably where I'd spend most of my time, is in figuring out whether OptionsScreen is simply trying to do too much. Just based on what I see in the constructor, I would assume that it is probably drawing the entire screen, including choosing fonts and images, as well as playing sound effects when things happen, and making changes to volumes of sound. It's quite a bit, but other than more fully developing a UI framework for yourself (which is a monster task) I'm not sure where you'd split this particular case up.
Bottom line: while I agree that fewer constructor parameters is a good thing, what I see here (a) doesn't seem that extreme and (b) actually shows a lot of good design choices to begin with. You should constantly be evaluating your design to see if you've got too many dependencies, which you're doing by posting this question in the first place, but this specific example doesn't seem particularly egregious or offensive to me. My preference would be to keep it as is, rather than start making some of these things static/globally accessible.