There are reasons to still want it, despite its newness; for example, the latest updates bring huge improvements in metadata efficiency (low metadata overhead -> more metadata in the cache -> larger working set). Someone on the IRC channel reported it's somewhere around 20x faster than most filesystems when it comes to "iterate millions of files recursively", blowing everything else out of the water. (This seems somewhat synthetic, and I'd say it mostly is -- but OTOH, "tons of files in a directory" being really slow is life, and has bitten me multiple times in a prior job). In general, improved metadata efficiency helps everywhere, though. For example, if you're doing backups on a really big filesystem recursively, you'll have to traverse the metadata inodes a lot to get e.g. last modified time. bcachefs will likely do awesome here in terms of performance.
Another unique feature I recall is the fact it has very very good tail latency -- bcachefs almost never blocks on I/O unncessarily, so you do not get random 'lag spikes' when things like the page cache get flushed out (which may halt some other I/O ops). This makes the system feel much more consistent, in general.
There's lots of good info in the architecture document and Patreon posts from Kent:
https://gist.github.com/liloman/d525131fab9b9a440140905921e9...
I'll give it a try on bcachefs. :)
The script needs a 512MB spare disk partition and some basic changes but the fundamental work is there.