They are both useful, and the ultimate solution, for different cases. BTRFS has no future, and ext4 is purely a legacy solution (also ironic, given XFS is older than ext4).
The mailing list gives interesting insights on what the developers are working on.
Its XFS which never had a future because it lacks features which modern filesystems have. Adding these features would be akin to making a new filesystem (which could contain the acronym XFS).
The only real (integrity) issue BTRFS currently has is write hole in RAID5/6. Its a long standing issue...
I want it to be stable and safe already, but realistically, we still need to wait.
This is FUD.
Btrfs is actively developed and its problems and limitations are acknowledged by upstream in an honest way. Many people DO use it with no more problems than they have with XFS or OpenZFS.
The only people who say "Btrfs is dead" are those who don't use it. It's a bit like people who snigger at the whole "Perl looks like line noise" trope without ever having writting a line of Perl in their lives.
In every report that I have seen of Btrfs doing something bad is when somebody (myself included) has done something incorrectly, not read the docs, not consulted an expert before doing something complicated, not taken the time to understand how it works, using a suboptimal or flakey hardware/software stack underlying it.
Have you seen how strict the FreeNAS community is about using proper, server-grade hardware and configuring the system properly to prevent data loss? This is a very good line to stick to.
Unfortunately Btrfs doesn't have the same consistent message but if it did then there would be fewer problems.
I regularly use Btrfs at home and so far I haven't had any problems. I would not use it in production when other people's data is on it YET.
One reason is technical, and it's too much of a cognitive burden these days when combined with other people's data.
The other reason is because of customer expectations, i.e., because of FUD that people like you are spreading. If there was some data loss, the customer would be angry at me for choosing Btrfs because "everybody knows" that it's unstable /s. If I am using ZFS then there's less of a chance that customers think I make bad decisions and there is a small chance they will be more forgiving.
Mdadm + LVM + XFS is an excellent alternative. The only reason that I don't use this more often is because snapshotting requires twice as much disk space as you plan to use. Otherwise I probably would be using this stack exclusively.
Getting back to the original "Btrfs has no future" nonsense, the only reason this is true is if people make it true. Therefore, one important reason I use Btrfs is that I want to see it succeed. That can only happen when people actually use it and advocate for it in a positive and honest way.
Please do not put your words in other people's mouths.
There are many people who did try btrfs and lost their data. And it was not because they did not read the docs or used flaky hardware -- for example, our org lost the data after the sudden power failure. Maybe this was our fault, be we switched to XFS on the very same hardware and did not lose any more data, despite having more power failures.
If your point is to have people use btrfs, you are not helping it by saying things like "it is user's fault every time". Nor does it help to dismiss people's experiences as FUD. Acknowledging its limitations, and saying "yes, it was bad, but as of 20XX it got much better" would be much more effective.
There are of course environments where XFS is fine but it's failure cases are pretty bad. I accidentally (wasn't paying attention) used XFS at home once on a NUC that was my UniFi controller and Pi-Hole; any time it lost power it'd hose the partition and make it unmountable. I'd have to go find a monitor and a keyboard and boot it single-user to recover.
My fault (we were selling the house and buyers love throwing breakers) but still not awesome. I run boot drives as ext4 exclusively now and I definitely pay more attention during setup.
An admittedly extreme example: if you're in a data center with ineffective/insufficient remote hands, you probably very much want the server to come up so you can deal with your problems faster and better. That they could come through, on some timetable, and slap a new OS on there/restore a boot volume from the backup you hope you have is nice, but it isn't the same thing as being able to SSH in and rescue yourself.