A number of rituals have developed over the years, due to real bugs in space management on Btrfs. The most significant change happened in 2016, the “ticketed enospc infrastructure”.
My suggestion is to not do these rituals anymore. I don’t babysit my Btrfs file systems, whether on HDD or SSD. I don’t expect other folks should need to either. If there are edge cases where there is poor performance, they need to be reported as bugs/enhancements - and yeah in that case, maybe we end up with new rituals to alleviate the problem in the short term. But those mitigations should be automatic, and specific to rotational drives.
It is true that Btrfs lacks many of the locality optimizations ext4 and XFS have, based on rotating media. What it does instead is make heavy use of delayed allocation so that small random writes turn into more sequential writes. And also inline extents, where small files are included in the 16KiB (default size) metadata block along with the file inode. My opinion is if you have to do maintenance rituals to maintain performance, the file system needs optimization to fix it, not user initiated maintenance rituals.
It’s completely reasonable to continue to use ext4 or XFS if you prefer it. And yes that will still be a custom partitioning install time option for the foreseeable future.