Reading the comments so far, I see that there's a little of that 2FA "pushback" I was talking about, so let me address some concerns:
Q:
Will this new system be a hassle to use?A: No, it doesn't change anything fundamental about SMF's login code. If you enable it, then all that happens is that a small piece of additional logic is executed (to verify the entered OTP). This verification takes place in the same code path as password verification (that is, there's no extra "step" involved, you either type in an OTP, or you just ignore that field if you haven't enabled 2FA). After a successful login, it won't bug you again (and everything else, such as cookie duration, continues to work as before).
Q:
Will I have to use my mobile phone?A: No. This is just an implementation of
RFC 6238 (TOTP: Time-Based One-Time Password Algorithm). Technically, it has nothing at all to do with mobile phones. You can generate the OTPs needed for login with desktop software (like KeePassXC, which I use) or even with your own script if you're industrious enough (after all, the OTP is just a function of your "shared secret" and the current Unix timestamp). Of course, a lot of people do find mobile authenticator apps to be convenient, and this system works fine with them, too.
Q:
Don't most people put their "shared secret" on the same device that they log in from? Isn't that stupid?A: It's not ideal, but it's far from stupid. There are still important advantages to be had even with this "single device" configuration. Your account will still be protected from phishing, and (in a lot of cases) it will still be partially protected from keyloggers, clipboard sniffers, and certain other types of malware (i.e. depending on how it's stored, it can be much harder for malware to exfiltrate your shared secret than it is for it to read the clipboard, etc.)
(Thanks to the people who left kind words, I appreciate those. Not gonna lie, the merit bombs are appreciated, too.) 