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).
yes, it does.
btfs is already the default in SUSE derivatives. It remains to be seen how the other distributions will handle it within the next ~3 yrs.
its only just become stable enough to be usable in production.