The real problem with making it a default is that there’s too much variation to make “default on” a safe choice.
How is the drive connected? An “external drive” usually means USB, and TRIM is a SATA protocol command — it’s not generically supported over USB (or FireWire). Some external drive controllers, like Western Digital’s, map the SCSI protocol UNMAP command to a SATA TRIM command, when using the USB SCSI interface, but that’s entirely dependent on support in both the OS and the external USB-to-SATA interface controller.
One of the things that makes TRIM a good option for SATA SSDs is the drive’s native command queueing (NCQ). As that Arch wiki page you linked to notes,
Warning: Before SATA 3.1 all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying Periodic TRIM less often is better alternative. […] depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM.
UAS (USB-Attached-SCSI) is also required for command queueing when using USB storage, otherwise any type of TRIM commands would be non-queued. So, continuous TRIM could severely degrade performance of non-UAS external SSDs.
All in all, it’s just not very safe for the OS to cavalierly attempt to activate TRIM for external filesystems just because some might support it. The potential problems are far greater than the potential issues from not having it enabled. For the longest time, Apple didn’t even enable TRIM on internal SSDs unless they were original equipment, MacOS users installing their own aftermarket SSDs had to use a
trimforce command to turn it on. (Not sure if that’s still the case today.)
If you’re really worried about it, and you’re sure TRIM works on your external drive, you can always
sudo systemctl edit --full fstrim.timer and reduce the
OnCalendar=weekly value to a more frequent interval.