That's nonsense and couldn't be affected by BTRFS short of something catastrophic happening (probably in the kernel).

The main downside for NVME that I'd be aware of is that BTRFS is a lot slower to write lots of tiny files than something like XFS (which is generally the fastest filesystem available). I'd guess this is due to BTRFS's metadata overhead, which includes writing two copies of metadata for redundancy. I have a very fast gen 4 NVME and I can get ~2GBPS tiny file write speed with XFS and ~300MBPS tiny file write speed with BTRFS. IMO this is negligible though, because tiny files are inherently tiny - 300MB of tiny files is a lot of files for 1 second of effort. Also, usually read speed is more important than write speed for day-to-day tasks. Large file writes and large/small file reads are roughly the same though, with any small advantages going towards XFS.

BTRFS will never be faster than something like XFS because it has way more features - with how fast NVMEs are I personally think it's worth trading some of that ludicrous speed for features like data checksumming, compression, and snapshots. On the flip side, BTRFS is a very good idea to run on slow HDDs because its transparent compression will actually increase the drive's speed, as the act of compressing/decompressing is way faster than the act of reading physical data from rust.