python-cef, which has support for handling downloads and uses the chromium-embedded-framework. But my understanding is that the chromium-webdriver solutions works just fine.
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
options = Options()
An add-on could likely intercept the traffic and initiate downloads, you may try asking the DownThemAll! author for hints.
DownThemAll does not intercept traffic. It gets around this issue by never "clicking" on the download links, instead it adds them to an internal queue. If you click a link with DownThemAll (or any other extension I've tested) it still prompts for blocking user-input. It serves a completely different function and operates in a completely different way. Remember, the problem isn't actually downloading the content, it's the browser entering an uninterruptible blocking state when you try to use it for automation.
If you're intent on not fixing this I do have a solution working using chrome. For various reasons I'd prefer to use firefox, but I understand it's a fair amount of work to fix a niche problem. Still, as you can see from the various stack-overflow posts, it's not that niche of a problem.
I probably could hack something together by intercepting HTTP-requets, modifying headers and all that, but where I'm using this for web-archiving the archive would record any changes I make, causing WARC-playback to fail when users tried to download that same file over again. I note that none of the existing download-manager plugins use that technique, so I'm skeptical that it would even work, and it's a lot of work for an exploratory solution to a problem that chromium doesn't have.
Alternatively there could be a webextension api for pragmatically handling download links without blocking user-prompts, or perhaps a flag equivalent to chrome's "download.prompt_for_download", but that actually works for mimetypes that aren't explicitly set in