All open source developers want users. Users means more bug reports and often more developers to contribute to the prokect. In addition, the greater relevance also means it's more likely they will be able to get companies to be able to pay for them to do what they do, conferences to invite them to talk about their projects, etc. (It's for this reason that when the IMHO over-aggressive enforcement of busybox license forcing people who get sued to release code on code unrelated to busybox has caused FUD amongst Linux embedded companies, the emergency of a replacement toybox project which avoids these issues has caused so much dismay amongst the busybox development community.)

Given that Dave Chinner is one of the primary developers of XFS, it's not surprising that he wants to promote XFS. And to be fair, XFS has not gotten as much attention as it has perhaps deserved based on technical considerations alone (as has other perfectly capable filesystems at the their time, such as JFS) and that's no doubt frustrated him. In addition, the work he has done to improve XFS removes one of the significant performance bottlenecks often seen by desktop users and developers, and he should be saluted for that.

That being said, it's also true that in many cases the file system is not the bottleneck, and so other issues that aren't tightly focused on performance (i.e., the quality of the userspace tools such as e2fsck and debugfs for ext4, and their equivalent or lack thereof in other file systems), familiarity by sysadmins, data recovery services, etc., ease of upgrading of existing large, production file systems, and so on.

In addition, it's dangerous to draw conclusions from a single microbenchmark such as fs_mark alone. It's not common that you have workloads which create thousands and thousands of small (< 64k) files in parallel across lots of CPU cores at the same time, on the same file system. So using this this benchmark alone to say that file system X is more scalable than file system Y is just not going to tell the whole story. Personally, I like to use microbenchmarks as a tool for improving a file system, and not as an argument to try to get people to switch from one file system to another. Unless someone's use case is exactly mirrored by the microbenchmark, I personally find this approach to be a little dishonest.

I will say that at the moment, many of the developers who have been working on ext4 are employed by companies who are using ext4 as part of a cloud data storage stack. This is why there has been changes such as no journal mode (which is great when you have consistency guarantees being provided by a cluster file system above you, since they have provide the file even if an entire server's power supply has exploded), and good performance when under severe memory pressure (funny how most benchmarks are done when the only thing running on the server is the benchmark, so there is no competition for the CPU and for system memory --- XFS in particular have proven to be a memory hog, and others have noted severe performance degredations and in some cases stability problems, under memory pressure; not a problem on a stand-alone file server, but not so great if you are also trying to run VM's or other applications using the file system on the same machine). Arguably some of these improvements don't mean as much for desktop users, although I believe some of the performance enhancements we've made have also trickled down to help the desktop.

XFS, in contrast, has been focusing a lot of attention on the desktop use case, and they've traditionally owned the big stream writes, HPC workloads using huge servers, huge memory, and huge RAID arrays. It's good that XFS has made these improvements, and I salute them for it. But to state that these two workloads are the only ones which are important, and therefore they are the file system of the future, may be overstating matters --- with all due respect to Dave and his many years of experience working on XFS.