There's no such thing as "smarthost fingerprint". These are TLS certificate fingerprints, which just happen to belong to SMTP relay servers (smarthosts) in this context – but everything here applies equally to IMAPS, HTTPS, FTPS... anything that uses TLS.
TLS certificate fingerprints usually don't depend on the client at all: they're a SHA1 (or SHA256) hash of the server's certificate, and generally servers use the same certificate for everyone.
But one exception might be servers behind a load-balancer: large sites might have several servers behind a single name, and although they might share one certificate, that's nowhere near guaranteed – they could easily use 20 or 50 certificates at once, too.
And even for the same server, it is actually very likely that the fingerprint will change – it will be different every time the certificate is renewed (because the validity dates change) or reissued for any other reason (new private key, or new issuer, or new domain name...)
While certificates used to be issued for 3–5 years in the past (and manually installed), the new practice is to automate the process and use short-lived certificates, usually 90 or even 45 days. Google has been doing this since approx. 2014, and that's how Let's Encrypt works since day one. (By CA/B Forum rules, even "standard" long-lived TLS certificates are now capped to 2 years.)
So the only time the tls_fingerprint option is useful is when you know exactly when the certificate is supposed to change (e.g. if you're the person who's changing it). Otherwise it will just keep breaking your configuration every month or two.
In practice, at least Linux distributions are reasonably fast at updating their CA certificate packages. (I mean, if they don't, are you sure you even want to run that OS on your computer at all?)
So I would say the article is trying to scare its readers with the wrong problems. A much bigger concern is that the CA cert packages often include a few shady, government-controlled CAs from various countries.
Alternative 1: If you want, you could make a custom tls_trust_file containing just the single CA which the provider uses: e.g. tell msmtp to only trust DigiCert and nothing else. This is a common method, called "CA pinning". But it still has some chance of breakage, as server admins are free to choose what CAs they'll do business with.
Alternative 2: Some programs support a different fingerprint type – SPKI fingerprints (hashes of subjectPublicKeyInfo). These only represent the raw keypair and don't include any additional certificate metadata. A server could periodically renew its certificate while keeping the same keypair and therefore the same SPKI fingerprint.
(However, even if your client supports SPKI fingerprinting (msmtp doesn't), it'll only have an advantage if you know that the server admins renew their certificates this way. Most of the time they don't.)
