I don't believe it's an easily changeable tunable with a config flag or sysctl setting, no. You could of course modify the kernel source code, but there's probably lots of unintended side effects to this - your setting is alright for most Linux distros, but what if someone picked one that overlapped with ephemeral port ranges? Or if you're running software that the commonly used port binds to something under 16382 but above 1024 - now you have to reconfigure it, or set up temporary privilege escalation so it can bind to it before going back down, a la httpd.
It's also a bit of a contract with the client - on Linux something below 1024 is ALWAYS privileged so you know you're not connecting to a fake sshd and giving away your password or current 2FA token unless that system has been totally owned. If you modify the kernel you're modifying that contract - are you sure that this system has modified kernel?
That's really my issue with this whole idea (and one of my top level comments goes into this in more depth) - but there's a lot of unintended side effects from these obscurity changes that people don't know about or think about.
Meanwhile there's lots of well understood practices that provide real security that solve both the issue of noisy low effort attacks while also providing real security against determined attackers. VPNs and jumphosts - why should SSH be internet accessible in the first place? Use key based auth, as well as 2FA.
Port knocking is... interesting... in theory, but it increases complexity for the users at a similar level of requiring them to use a VPN or jumphost (or both), but has additional flaws that they don't have - if they have access to sniff your traffic via some means, they can figure out the sequence and now they have completely removed it as a layer of security. They don't even need to be able to decrypt the traffic - just see the destination ports.
Is this level of attack something most of us have to worry about? No. But if for similar levels of effort we can get better security, why would we go for the weaker form, even if it's unlikely we need more? If for some reason you do have a dedicated attacker, you're better prepared. You can also extend it to provide even more security - lock down SSH to all of your production hosts to only the jumpbox(es). Alarm on any attempt production host to production host SSH attempts. Easily audit ingress SSH access on a subset of hosts. etc.