なぜヘッドレスブラウザはダウンロードを実装しないのか

タイトルの「ダウンロード」というのは、正確には「Content-Disposition: attachment」ヘッダ付きで帰ってくるレスポンスを意図しております。
(まあ一般的な「ダウンロード」という意味だとHTML持ってくるのもダウンロードですしおすし)

で、「自動でサイトを巡回してデータ落とす」ようなスクリプトを書くにあたってこの手のレスポンスでその「データ」を返された場合、

• PhantomJSは未対応。ソース読んでないから分からないが、エラーにもならないようなので無視してる？
• CasperJSもPhantomが未対応のものに対応するわけもなく。
• SlimerJSはダウンロードダイアログを出そうとしてXULRunnerがずっこける。

なぜ対応してくれないのか？(Phantomには対応版のForkがあるらしいけど……)というと、SlimerJSの挙動が暗にその理由を示しているのではないかと。
RFC2616(Hypertext Transfer Protocol -- HTTP/1.1)にはこうある。

RFC 1806 [35], from which the often implemented Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of
the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC 2183 [49]
(which updates RFC 1806) for details.

「そっち見れ」と書いてあるRFC2183(Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field)によれば、

There are security issues involved any time users exchange data.
While these are not to be minimized, neither does this memo change
the status quo in that regard, except in one instance.

Since this memo provides a way for the sender to suggest a filename,
a receiving MUA must take care that the sender's suggested filename
does not represent a hazard. Using UNIX as an example, some hazards
would be:

(実例省略)

ここでは主に「filenameパラメータをそのまんま使ったら大惨事だろJK...」とだけ書いてあるが、つまり
このタイプのレスポンスは本質的に何が送り付けられるか分かったもんじゃないので危ない
ということで、従って
まともな(HTTP)エージェントは、必ず人間の了解を取ってからレスポンスボディを保存すること
というお約束になっている。
つまり、
このタイプのレスポンスを人間に確認も取らずに保存するような奴はRFC違反のダメエージェント

……そりゃ、誰もやりたがりませんよねorz

じゃあどうしたかって？Slimer(PhantomでもCasperでもいいと思う)からクッキーやらフォームパラメータやら全部吐かせて、HTTPを直に叩く別スクリプトに食わせて処理しましたですよorz
(「RFC違反のダメエージェント」をてめえで書く分には自己責任じゃいということで……)