Two years later, and I have an answer, after reading this: https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/SysadminGuide.html#Subvolumes

which was linked from the Arch Wiki, but it is the old wiki, which is obsolete and no longer updated. Basically, in a nested subvolume layout, the nested subvolumes inherit mounting options of their parent subvolume. This might be changeable, but it's the default.

On the other hand, separate subvolumes have their own mount options. Although not really important for a swap file, since the file itself can have copy on write features removed, you might want this if you want a subvolume containing folders of data where you want copy on write disabled for performance purposes. This matters for things like postgres, which has it's own alternatives to journaling/CoW:

Because WAL restores database file contents after a crash, journaled file systems are not necessary for reliable storage of the data files or WAL files. In fact, journaling overhead can reduce performance, especially if journaling causes file system data to be flushed to disk. Fortunately, data flushing during journaling can often be disabled with a file system mount option, e.g., data=writeback on a Linux ext3 file system. Journaled file systems do improve boot speed after a crash.

From here: https://www.postgresql.org/docs/18/wal-intro.html

And then the other benefit of a top level subvolume is management. You can mount it anywhere you want. You can mount it independently of other btrfs subvolumes, meaning you could share a swap file between two installed distros to save space, although this breaks hibernation, so you probably wouldn't want that. It's just that top level subvolumes give you flexibility nested subvolumes don't.