That's a valid observation of one of the reasons I won't use git-send-email.
I have limited mental resources, and given the choice between a tool where I have to spend half an hour before I can begin using it, and a tool which will guide me, I'll always choose the latter. After I'm done, I can even forget I ever used the latter tool! It's a boon for one-offs.
Keep reading, there's more criticism on other aspects of the tool.
After reading through the rest of the post, I do see your point. When I last tried it, I thought that most of the email formatting should be done with git format-patch and then git send-email should be used to actually send the email without having to answer any questions.
That would address one of your concerns about saving the email on disk and also ensuring that the headers have the correct contents.
If the project's contrib document contained information about what settings to use for format-patch and send-email, then the process would be much more seamless. I haven't looked at the kernel (or subsystems) documentation on that. The git project itself doesn't seem to contain that information though.
Regarding your other point about using your email client to handle sending the emails, git does have a utility called imap-send that would allow you to upload the patches to an IMAP folder, which, I believe, would allow you to then send the messages using your MUA of choice instead of git send-email.
I have limited mental resources, and given the choice between a tool where I have to spend half an hour before I can begin using it, and a tool which will guide me, I'll always choose the latter. After I'm done, I can even forget I ever used the latter tool! It's a boon for one-offs.
Keep reading, there's more criticism on other aspects of the tool.