Another aspect:
Java is a static language with quite strict features. This means that many things that would be quite open or dynamic in other languages (c/f Ruby, Lisp etc.) are strictly determined.
This is a general design decision. The "why" is hard to answer (well, because the designers of the language thought it would be good!). The "what for" is pretty clear: it lets the compiler detect a lot of errors, which is generally a pretty good feature for any language. Secondly, it makes it comparatively easy to reason about the language. For example, it is relatively easy to create formal correctness proves in (subsets of) the Java language; as comparison, that would be virtually impossible in a dynamic language like Ruby et al.
This thinking permeates the language, for example, the enforced declaration of possible exceptions that a method can throw, the separate type of interface
vs. class
to avoid ambiguous multiple inheritance, and so on. For what it is (a static imperative OOP real-world language with strong focus on compile time error handling) those things are actually quite elegant and powerful. They come closer to theoretical (science'y) languages which are purposefully made just to explore some of these issues than any other real-world language before (at that time, mind you).
So. Having a strict void
type is a clear message: this method does not return anything, period. It is what it is. Replacing it by the enforcement to always return something would lead to either much more dynamic behaviour (like in Ruby where every def has an explicit or implicit return value, always), which would be bad for provability and reasoning; or to massive bloat by using some other mechanism here.
(And N.B., Ruby (for example) handles this differently, and its solution is still exactly as acceptable as Java's, because it has a completely different philosophy. For example it throws provability and reasonability completely out of the window while putting a large focus on extremely high expressiveness of the language.)