I've also encountered this issue when upgrading an application's ojdbc driver recently.

The javadoc for how milliseconds are to be handled are stated in the javadoc:
Set Time:
Sets an existing Date object using the given milliseconds time value. If the given milliseconds value contains time information, the driver will set the time components to the time in the default time zone (the time zone of the Java virtual machine running the application) that corresponds to zero GMT.

The fact that the Oracle driver no longer does this is clearly a violation of this contract.
On top of that it effectively breaks applications relying on querying for date objects as the dates are matched including hours seconds minutes and millis and results will be missed.
The behavior might or might not be problematic depending on the time zones you are running in.
If you happen to have a timezone with adjustments that are in line with GMT you are in luck but if you're running for example CET you will have issues with some dates precluding 1977.

The simplest workaround seems to be not to upgrade the driver and stick wtih ojdc6 driver version. No exactly sure in which version the behavior changed.
Oracle's suggestion of applying a patch seems unworkable and there is no guarantee they will will continue to provide patches for its driver's future versions.

The workaround I've implemented is to convert the date to be persisted to gmt timezone at 0 hours. All dates in the application I'm working in have a custom object wrapped so it is a matter of updating the converter for that type. The problem seems to be solved for the dates I've sampled.

An alternative solution might be to convert the date to be persisted to a LocalDate and then use java.sql.Date.value(LocalDate localDate) to create the final java.sql.Date object to be persisted. I'm not sure it will work as the doc states:

Obtains an instance of Date from a LocalDate object with the same year, month and day of month value as the given LocalDate. The provided LocalDate is interpreted as the local date in the local time zone.

Meaning if your system's timezone is set to something else than GMT it might break the contract specified earlier.

It might be considered overkill but implementing this solution in hibernate converters might provide some protection against misbehaving drivers.
However the problem should be fixed at the root which seems to be Oracle's jdbc driver implementation.
Based on some prior googling it seems like Oracle might not comply with changing this behavior as they seem to argue that "their" solution is the right one.
Implementing this solution internally should ease the upgrade process for the users of this driver.