In a sense you do. Most OO languages like Java are procedural languages as well. But OO offers the "advantages" of bundling everything in a given work-unit together. While something like C may leak state or names all over the place and you end up with similar/same methods being improperly used and that all needs to be tracked or disambiguated somehow.

Lots of people consider namespacing and packaging up your source well as a way to do this. I think that works up to a point, but once you start hitting really big projects, I think the way that Java enforces and cleans up some of this optional stuff and makes these things as part of the language makes it a little more natural. Instead of having to be careful about your work (meaning if you aren't something will go wrong), you simply have to do the best practice to make progress. On smaller projects, where the manager can review every commit, every line of code, every way that work was done, and can enforce a cohesive and singular idea about how it should be done, it can work. But once the scope expands beyond what one management drone can handle it starts to become something that falls into the next layer of Management Science abstraction.

tl;dr Making things that are optional in some languages into requirements (or the code won't work) seems to have been a good optimization.