Please do explain why it should not be the default.

1) I tried to summarize here: https://wiki.archlinux.org/index.php/User:Seblu#Should_a_daemon_be_automatically_restarted_when_it_fails.3F

2) For comparison, in our repositories, we have 322 services files; with only 20 packages with Restart=always.

I am certain that most system administrators that install and run a mail daemon consider that this is one of only a handful critical services. If the server fails due to a bug or a misconfiguration, it should automatically be attempted to restart it to avoid downtime whenever possible (since any loss of emails would be terrible); later the administrator would inspect their logs, notice the server had an issue, and calmly try to diagnose it knowing that, in the meantime, this critical service is still being fullfilled as best it can.

The wiki page you link to reads "Some corner case may be found in vital daemons." and I argue that a mail server is definitely one of these. The common case is for system administrators to want their mail servers to be automatically restarted, and this is what our default service file should implement. However, as your wiki page says, the administrator is free to override this if they wish.

Also, your comparison with other packages in our repos can be simply explained by noticing that most daemons we ship are not as critical as a mail server.

Thanks for your feedback, I will improve this page.

IMHO, the mailer daemons are not critical, likewise for almost all daemons; the context where they are used may be critical or important.
A mailer daemon on a my firewall, is not critical, but the one on my MX server is. We can argue that any daemon can be critical for some reasons.
I named critical daemons those which are mandatory to get back access to your computer. Because you need them to fix the issue.
I think it's a mistake to try to define if a daemon is critical or not in order to choose the default.

Possibly, for a know daemon which exits erratically, Restart= could be used. But postfix is stable, I never saw it crashes since the decade I use it. Moreover it is used in many UNIX systems which doesn't offer a Restart feature. Even Arch, some years ago, use it without auto restart. By default this daemon is renowned working.

I also take in consideration that auto restart hides errors and degradation of a service. I'm persuaded that trying to hide should not be the default.
We should reserve masking errors to a deliberate choice. "Explicit is better than implicit".

As an example, the issue I got recently with postfix, which led to this BR, was not fixed by the Restart=always. Quite the opposite.
I'm curious, did this feature already help you to prevent a postfix breakage? In the case of my mx service, I have multiple postfix daemons on multiple machines.
This is what a critical service deserve.

No, postfix has never crashed on me, and sure many people use it without proper supervision or (the other extreme) on multiple hosts like you do. All I'm saying is that systemd's Restart= provides some kind of failsafe. You argue that, in some way, it's unnecessary and, in another way, it's not enough. True enough. But it's still something that in certain situations will prevent you from losing mail. Surely we do not have to debate whether losing mail is critical...

Why should sshd be automatically restarted but not postfix? Is having to reboot your server that much worse than losing mail?

If you insist to have Restart=always removed from postfix.service, I suggest we have a poll on arch-dev-public to ask devs and TUs that have postfix installed whether they want that option on by default.