It is OK that Duration-Date doesn't make sense even though Date-Duration does because subtraction (unlike addition) it not commutative.
The Date(long) constructor takes a milllisecond date value in the 1970 epoch (the Unix epoch), not the int days duration used in DGM's date arithmetic. It is the same precision as the duration in TimeCategory, but still a different type than a duration (even if expressed as long milliseconds in a epoch).
If automatic conversions were supplied like they are for number system, then we could have a date system that unifies (or at least hides the mess) of Java's multiple date types. If an exact match isn't present, then a conversion is made. That would happen for method calls and assignments.
A starting step though would be to implement asType which seems like a no-brainer to me (I just tried it and see that it doesn't work).
The reason the DGM date methods specialize for java.sql.Date is so that they can return that type when doing arithmetic. This might be a trouble spot. If someone does CallableStatement.setDate("x", new Date('1/11/2008') + 7) then we'll wind up with a java.sql.Date even if we didn't start with one. The trouble might arise for folks who do stuff dynamically (using Object or somesuch) and we'ld give them a Calendar even though they started with java.sql.Date. But the java.sql stuff will deal with Calendar as well, so that is probably the right thing to do for dynamic folks.
As for why I provided the DGM.minus(java.sql.Date, java.sql.Date) specialization is I was just following what DGM already did and I was just trying to fill in the gap. From this further examination I can see that it is not needed in this case.