While one could, hypothetically, have made
java.util.collections for all of the new collections that were part of the collections framework, the thing is that there were some collections classes that existed prior to them.
java.util.Dictonary (javadoc) would have been in a separate package than
java.util.Map (javadoc). Similarly, you have
java.util.Vector (javadoc) implements
java.util.List (javadoc) now.
Hashtable to a new package is out of the question, and making a copy of the code or subclassing either in a new package causes even more headaches (I don't even want to think about the mess that would cause).
When you look at the java.util package, you will see that it is mostly the collections with a few other utility classes hanging out in there.
So it just doesn't make much sense to try to place the new classes in a different package.
Contains the collections framework, legacy collection classes, event model, date and time facilities, internationalization, and miscellaneous utility classes (a string tokenizer, a random-number generator, and a bit array).
java.util continues the collection framework. That is first and foremost. The only collections that are in a different package are the ones used by java.util.concurrent which is focused on concurrency. These are still considered to be part of the collections framework. From java.util.concurrent.ConcurrentNavigableMap:
public interface ConcurrentNavigableMap<K,V>
extends ConcurrentMap<K,V>, NavigableMap<K,V>
A ConcurrentMap supporting NavigableMap operations, and recursively so for its navigable sub-maps.
This interface is a member of the Java Collections Framework.