The two articles you are mentioning are both about static keys, but different use cases.
When it comes to securing the VPN tunnel encryption, it is far more preferable to have server and client negotiate an encryption key that is used only for a limited time, and then replaced with another one. This is according to the principle of Perfect Forward Secrecy. If you use a static key for all VPN sessions encryption and never rotate that out, then the moment that key is compromised, all the data is compromised. With Perfect Forward Secrecy you instead get a new encryption key with every session, and even mid-session it gets rotated out. So the compromise of one such key affects only the data encrypted with that key, but not any other data.
Since it's pretty much automatic in OpenVPN to do these ephemeral automatically negotiated keys, it is vastly preferred to go with Perfect Forward Secrecy.
The other article you reference is about TLS auth. And admittedly the article is a bit out of date in the sense that nowadays we would advise TLS Crypt v2, so that's something we can improve on. With TLS auth and TLS Crypt we are having server and clients agree upon a static key to add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack. Basically if you send packets to probe the OpenVPN server, and these packets are not signed by this shared key, these packets are discarded very early on in the process. Only clients that have a valid key can even start a connection with OpenVPN. Clients that don't have it don't even get to the authentication phase. So it's a good way to harden the server.
But, of course, if that key is leaked, then whoever has that key can start a connection to the OpenVPN server. But then they would still have to pass authentication to get any further. Still a valuable feature to add.
Most important to understand about this is that, like an onion, the outer layer of protection is removed if this TLS auth or TLS Crypt key is compromised, but there are more layers, like client/server certificate verification and credential authentication. But if the static key for data encryption is leaked, then someone that captured your encrypted data can now decrypt all of it that was encrypted with that particular static key. So that's the crucial difference.
For the record, TLS auth and TLS Crypt work with one key shared between the server and its clients. TLS Crypt v2 allows to have unique keys per client, which could also be revoked if they get compromised.
Edit: a bit more to add;
The function --secret (for static VPN encryption key) is on the way out, and --peer-fingerprint replaces it. Peer fingerprint does use certificates but not in a CA structure, it just checks if the fingerprint of the certificate on the other side is in a whitelist. If it is then it accepts it, otherwise it rejects it. Simple and no complication, this is also what for example WireGuard does.
Certificates are technically not required for VPN encryption key negotiation (PFS), you could run entirely without certificates. But without certificates you really only have credential-based authentication. Certificates are a really good idea though to prevent your client connecting to an untrusted server and spilling your authentication credentials there.
You could choose to only use a certificate to verify the server identity, but not implement client certificates at all. Access Server for example does this with its 'server-locked' connection profiles. You could do this with either CA trust model or peer fingerprint model. Up to you.
