Does that also shrink the partition? Otherwise you're not comparing equivalent things...
P.S. I realize an existence proof makes us mathematically happy, but it's a little disingenuous to suggest file system experience on Linux and Windows is comparable merely because of the existence of some uncommon file system with similar capabilities. The reality is most Linux users are on ext4 rather than on btrfs or zfs, and most Windows users are on NTFS rather than ReFS or FAT32, so their experience with shrinking file systems is not going to be remotely comparable.
Well, the answer more like "it depends on what you want, exactly".
In the specific example of btrfs there is an extra layer of indirection just like there is with ZFS. Filesystems live inside pools of devices, and when one is shrunk that leaves room for another one to grow. You wouldn't want to resize the physical volume or partition unless the device is shared with other types of filesystems.
(This is why ZFS and btrfs sometimes are referred to as "layering violations". Other filesystems expect the logical volume manager to pool devices into logical block devices.)
So resizing an btrfs filesystem absolutely makes sense even in isolation.
What you describe is accurate for ZFS, but not for btrfs. Shrinking a btrfs filesystem with the resize command only makes sense if you are going to follow up by shrinking the partition or other underlying logical block device (eg lvm). btrfs does not have ZFS's concept of a device pool from which multiple filesystems can be allocated.
It's close enough. A completely valid use case for shrinking a btrfs file system is to remove one of the physical volumes from it, of which there can be several. They can also be split into subvolumes, which is the canonical use case for partitioning your block storage.
Neither of those use cases involves the `btrfs filesystem resize` command. Removing a physical device is accomplished with `btrfs device remove`, and subvolumes don't have a capacity unless you enable the optional quota features (and even then, quota groups use thin provisioning, so setting a lower quota limit doesn't free up any space for anything else).
P.S. I realize an existence proof makes us mathematically happy, but it's a little disingenuous to suggest file system experience on Linux and Windows is comparable merely because of the existence of some uncommon file system with similar capabilities. The reality is most Linux users are on ext4 rather than on btrfs or zfs, and most Windows users are on NTFS rather than ReFS or FAT32, so their experience with shrinking file systems is not going to be remotely comparable.