This is just a variation on as far as read-access is concerned.
For write access, it certainly could be used to store malware on a user's system, but so can "Save As" or clicking a link with HTTP headers that triggers a download. Basically, the "Save As" dialog from browsers have the same issues.
It is not downloading malware that is the issue, it's executing it. So unless you can trick the user into navigating to an existing binary that is normally executing on the system, and have the rights to replace it, executing is not any different that triggering the user to put something in his ~/Download directory and asking him to paste a shell command.
The API doesn't not provide a way to mark something executable, and it should block you from obtaining write access to any file already marked executable just like many mobile OSs don't let you simultaneously mark a page in memory as writable and executable.
The last one looks like a flaw, I couldn't find anything in the spec that says "thou shalt not let the user open a file marked executable for write access", although it does suggest banning access to stuff like C:/Windows, /usr, /Applications, etc.
But what really bothers me is people making uninformed comments. Rather than knee jerk trigger anytime any browser API is changed without fully reading the spec and then actually pointing out any weaknesses, we get the same low signal commentaries.
So again, browsers already allow unaware users to be tricked with bog standard fileupload form elements and Save As dialogs. This just breaks a hardcoded high level UI into smaller reusable parts, and it actually adds more concerns over security than the original 1997 spec for file upload and save.