Not cool [0].
It's funny how CMSes tend to offer "clean URL" configurations (meaning that everything after the origin is 100% controlled by the CMS user) for requests served dynamically (database queries) but requests served statically (public files on disk) often end up containing implementation-specific junk (e.g., "/sites/" in the case of Drupal). The magic that makes clean dynamic URLs (rewrite everything that isn't a file to the boot script) should be expanded to make clean file URLs. Serving files would then need help from a script+db, but so what, that already happens for private files.
Obviously embedded assets that need to be fast (images, stylesheets, scripts, etc.) can't have a slow db query in the way. I'm only talking about files that are a first-class destination in the browser's address bar, like PDFs, and anything where the disposition is that it lands in your Downloads folder. Stuff that might be a search result or otherwise linked-to.
[0] https://www.w3.org/Provider/Style/URI
