Linux

They share the same partition, but they're treated like independent filesystems. They can have different mount options, so on one you can enable compression but not another some you may want to disable Copy-on-Write, etc. That's also useful so you can rollback a system update without also rolling back your data or vice-versa. You can also store multiple distros each in a subvolume and boot different ones all while sharing the same partition and not wasting space. If you have multiple users it's worth having a subvolume each so each user can independently rollback their home directory. Maybe you want your projects on a subvolume so you can snapshot and btrfs-send it frequently.

I don't use btrfs but on ZFS I have tons of datasets: steam library gets large recordsize and light compression, backups are heavily compressed and encrypted, VMs have a dataset tweaked for disk images, my music and movies also have a larger recordsize but no compression. I have one that's case insensitive that's shared with Windows machines and Wine stuff. I cap the size of caches and logs.

It's very versatile.

not to do the "read the manual" thing, but the manual is linked from archwiki and has at least 5 bullet points of limitations and all the whys to go with them

I personally prefer top level subvolumes (@, @home, @var-log, @var-cache), because it makes it easier to know which system folders are subvolumes and back them up accordingly. They are then mounted at their respective location under /.

E.g.. I do snapshots looking at the btrfs filesystem and its top level subvolumes. I'm not doing snapshots going from the mounted root filesystem. I.e. I'd do a snapshot of @home, not a snapshot of /home.

If you want to use backup/snapshot automation tooling, I'd recommend looking at how they expect the subvolumes to be set up. E.g. snapper and timeshift expect a specific layout (which can stil be done manually after OS installation, but why bother).

I think it is so that the subvolume can be mounted with different options. You can of course have a mixed layout which might be more convenient, so that say root and home subvolumes mount with the same options, but swap mounts with different options. And the top level never gets mounted at all.

toplevel (not mounted)
+-- @ (subvolume mounted on /)
    +-- home (subvolume, looks like a folder, same mount options as @)
    +-- usr (folder, gets snapshotted by @)
    +-- ...
+-- @swap (subvolume with different options, mounted on /swap)

I set mine up with a purely flat layout so I haven't verified this is true, but it sounds reasonable.

Here's the documentation I was looking at:

https://web.archive.org/web/20220103010302/https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Flat

Not a specialist, but I suppose it has to do with having different configurations for different top level folder. In Unix-like systems, every top level folder have a different purpose, and what works for the root may not for /tmp, /swap, etc.

In those example, no need to snapshot /tmp, as it is a forder whose file are bound to be deleted, and for which being able to restore has no use.
/swap is pretty similar ~~, and is often formated with a dedicated filesystem.~~
/usr often only change during the package manager transactions, so snapshots are often tied to that, while /home may be set to keep daily snapshots.