Because a lack of an accept attribute on the file-input element
has a defined meaning in HTML, and that meaning is accept="⋆/⋆".
Which, in turn, means that the form isn't putting any constraint on what's being uploaded at all, and so there's no reason to think that the form is asking for an image in the first place. At that point, it's asking for a file. Any file. And so it has the semantics of taking whatever file you provide it as-is, with no transformation necessary. Just like when a client requests `Cache-Control: no-transform` from a server. It wants the thing on the other side sent to it as-is.
And, it's important to support those semantics (and that particular implicit meaning for leaving out the `accept` attribute), because such "as-is" uploads have many use-cases. The form might be e.g. a computer-forensics or antivirus-signature portal, that wants an evidence file; or the interface to a hex editor or decompiler, that expects a raw binary with arbitrary extension in unknown format; or the SCP component of an old web SSH terminal emulator. All these existed on the web, and used <input type="form">, before the `accept` attribute was introduced. So "not using the `accept` attribute" has to retain semantics that are backward-compatible with that legacy.