But even on system where they aren't needed they're useful IMO, for me as a user. Magic bytes mean you have to seek into each file, and if you care about file types, it means anything that lists files has to do that.
The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file.
With NVMe disks or SSDs in general, this is a very cheap operation, even when done en-masse. Even when we were using HDDs, anti-fragmentation features of EXT3/4 kept that one seek pretty cheap.
As a test, I fed my whole documents folder (~3500 files) into "file" tool to see what it does (via "file -f $filelist"). It finished in ~1,5 seconds. I redirected the output to /dev/null to eliminate the overhead incurred by printing things over SSH, though.
While everything is fast for small n, the consideration of small for this operation goes a long way, AFAICS.
Oracle has a great write-up about EXT4 and its structure: https://blogs.oracle.com/linux/understanding-ext4-disk-layou...
How would webdev look like? At first the HTML goes into "document", the style into "style", and before you know it, you're re-inventing extensions as prefixes or suffixes anyway, and I prefer users.sqlite to users_db. I honestly don't even see a problem to solve, so even the "cheapest" solution seems needlessly costly to me.
I'm just happy to have the option around, I don't want to deprecate or against file extensions.
If you're interested, I can run some benchmarks on NFS and FTP as well, however.