There are several impediments here.
Persistence and HTTP cache clearing because of Field Def Identifier
First, about the route chosen for content/download. It includes the field def identifier. Having it implies that the SPI cache and HTTP cache are cleared when the ContentType is updated (at least when this field def identifier is changed). It currently is not, and it is an issue in all cases described below.
Adding the download url to the Field in REST
Using the FieldType Processor
One way was to use the REST Binary FieldTypeProcessor. It only receives the hash of the FieldValue properties. We don't have the data we'd need to generate the link (we need the content id and field def identifier).
Using the BinaryBase External Storage
The other one is to use the BinaryBase external storage handler, and add the downloadUrl property in the Field value directly. Semantically, it does make sense since the downloadable file is an externally stored data of the FieldType. The REST FieldType processor would then add the hostname, like it currently does with the var/site/storage path.
An idea could be to add a new PathGenerator implementation. But we only have access to the VersionInfo and FieldValue: we still miss the Field def identifier. We could fix this by adding another PathGenerator implementation, in a higher layer, that uses the public API to find out the FieldIdentifier.
But the whole idea would add ContentType related data to the persistence cache, taking us back to the original issue.