That touches a key element which many people seem to overlook. In this type of kernel development, correctness rules above all else. If something is incorrect, especially if it violates the contracts of the operating system or potentially loses data, the harsh lesson will follow.
Linus has absolutely had serious problems with being a jerk in his reactions, but the topics he is triggered by are nearly always about correctness.
Prove that it works, have data to back it up, be able to prove that the behavior is correct and it will get accepted. Some people may be upset if it modifies their domain or steps on toes, but the group is technical enough to know that correctness trumps emotion. Even if people don't like it, they can't argue against proven merits of correctness. Maintainers can and do add features they don't personally like after they're shown to be correct behavior.
Yes, Linus throws serious fits, but in the newsworthy ones he tends to be spot-on about the correctness. Usually he explodes after code is demonstrably wrong, and he can back it up with data or a use-case. Yes, he admits he has been a jerk at times, but very often they're around correctness. He often states his first rule is Don't Break Userspace. He has famously lost his temper quite often when people introduce serious bugs, or piggyback bugs on top of a broken system. A big blowup happened when someone imagined up a new return value from a system call that violated kernel requirements. A big blowup happened when a kernel maintainer was trying to use a compliance tool that ended up breaking kernel functionality. Go look through the cases of when he exploded and you'll see the reasons behind it tend to be the same: they really were bugs and correctness issues.
The explosion isn't "nice", but he'd already tried quiet correction earlier in the thread, people had mentioned moving it elsewhere until proven correct, and Linus had already addressed bugs in the system due to that dev. If the dev had been able to prove his system correct first and foremost, even if it implemented the unnecessary feature, that correctness would likely have satisfied the thread. In this case the developer couldn't justify it, but if he had been able to demonstrate correctness, a reply like: "I can show this behavior is correct by the book, someone can modernize and optimize it if needed but this implementation ensures it doesn't break userspace expectations around inode uniqueness" would have seen a totally different response. Instead he doubled-down on something he wasn't certain was correct, ended up not being correct, and took the heat because of it.