reiserfs was awesome but his failings as a human tarnished his work forever.
Ignoring Hans Reiser's personal life ...
ReiserFS was relatively "fast", in particular when used with large systems. I should really say "efficient", since ideally, the file system code itself should not be a bottleneck, instead it should get out of the way between the application and the disk drive. ReiserFS in particular handled the somewhat unusual workloads that occur in scientific computing (supercomputers) pretty well, for example mixes of lots of small files and some humongous files, and unusual layout of directory structures. There are several reasons for that: It used a database-inspired B-tree for much of the metadata (making directory operations relatively efficient when the size of the metadata is unusual), and it the combination of large blocks and suballocation that helps small files (small compared to the block size) be stored efficiently. It has this in common with for example BtrFS (another B-tree based system), and extent-based file systems (which includes XFS, but also ext4, and many short-lived or research systems, extents was hip and cool in the 90s and early 2000s). So far, so good.
The problems with ReiserFS were many. First, while it was efficient in handling partial blocks, that could lead to fragmentation for certain workloads, in particular those with unlucky combinations of file sizes. The stories I kept hearing was that while ReiserFS was pretty fast in many cases, in some cases it was awfully slow. And that is not acceptable to customers; in most cases, it's better to have predictable and reliable mediocre performance, rather than great performance much of the time with awful performance sometimes. Second, even in the bug-free case, it had some out-of-order semantics for metadata operations, which leads users to experience what they think is corruption or data loss (it really isn't, but if a customer thinks their data is scrambled, the customer is right, even if the fault really isn't with the file system). And it had bugs, which sometimes would lead to loss of the B-tree, which even fsck and manual recovery can't fix. Again, just like with performance, key to having happy customers is avoiding the worst case. This led to the jokes about the file system "no only murdering your wife, but also losing your files".
And I started by saying "Ignoring Hans Reiser's personal life". But in reality, you can't ignore it. The development of the file system was completely tied to Hans' way of doing business: he was an egomaniac, thinking of himself as god's gift to software development, with little regard for others. And while some of the ideas he used in his work were indeed good, they were not unique, and the same ideas were used by other developers at the same time. He then built a company by hiring inexpensive coders in the FSU, which is also where he hired women for his enjoyment, including his wife. This style of using coders who didn't have access to the "grand master plan" and were doing piecework fell apart after the center piece of the organization was removed to jail.
Now contrast this with other file systems: Many of then have an identifiable "central father figure" (say Ted Ts'o, Kirk McKusick, Chris Mason, Sage Weil, ...), but they also have a deep bench of people who understand the "why" and the design. This makes their development process scalable.