In my experience, Plesk configuration defaults have never caused a direct security issue. Sure, some of the settings can be improved and adjusted according to the needs of a particular server or a group of users, but apart from that, Plesk is doing just fine when it comes to security.
That being said, one could argue that Plesk has fallen a bit behind in terms of used email server features and that some of these unused features can have a security impact.
As you've mentioned, Plesk does use TLS and proper certificates (such as those issued by Let's Encrypt) for the email services. But Plesk does not support SNI at this time, although the underlying email software does. On linux, Dovecot, Courier IMAP and Posfix all support SNI (while Qmail could be made to support it), but Plesk does not enable SNI for any of the mentioned packages. This will only partially improve when Plesk 18 gets released.
Is Plesk's email less safe because of this? Well, yes and no, it depends on how the email server users set up their email software clients. In any case, the lack of email SNI support is an inconvenience for general hosting providers that use Plesk (or, better said, for their hosting customers).
On the other hand, S/MIME and OpenPGP are not dependent on Plesk in any way. S/MIME and OpenPGP provide end-to-end encryption on a message level and this functionality must be implemented by the email client software. If your email client supports it, you can use it.
As for the minimum requirements for a fresh Plesk server installation... I honestly think that in principle, the requirements haven't changed in decades. A freshly installed server that is partially hardened by an experienced server administrator before Plesk is installed and further hardened after Plesk is installed, is all it takes. Specific software requirements for a particular Plesk version are stated in the Plesk documentation and should, naturally, be taken into account. That's really all there is to it.
In reallity, the above sounds simpler than it is. Perhaps we could discuss how the world of server administrators has changed over the years, especially since affordable virtual servers started to float in the clouds, and since convenient terms such as DevOps were coined to describe (and provide excuses for) the new realities... but perhaps this is better left for another occasion...