All of those things come with tradeoffs.

Compression tradesoff compute vs i/o, if your system has weak compute, it's a bad deal. Most modern systems should do well with compression.

Dedupe needs indexing to find duplicates and makes writes complex (at least for realtime dedupe). I think online dedupe has pretty limited application, but offline dedupe is interesting.

Copy on write again makes writes complex, and tends to fragmentation of files that are modified. Free snapshots are only free when copy on write is the norm (otherwise, you have to copy on write while a snapshot is open, as on FreeBSD UFS). Copy on write offers a lot, but some applications would suffer.

Dynamic resizing (upwards) is pretty common now. Resize down less so. Zfs downsizing is available, but at least when I tried it, the filesystem became unbootable, so maybe not super useful IMHO.

Logical partitions, per user stuff, qos adds complexity probably not needed for everyone.

Because the vast majority of personal computer users have no need for the complexity of zfs. That doesn't come for free, and if something goes wrong the average user is going to have no hope of solving it.

FAT, ext4, FFS, are all pretty simple and bulletproof and do everything the typical user needs.

Servers in enterprise settings have higher demands but they can afford an administrator who knows how to manage them and handle problems. In theory.

Because it was extremely difficult to create something like zfs? And it was proprietary and patent-encumbered, and the permissively licensed versions were buggy until about 5 minutes ago?

That's like saying the Romans should have just used computers.

It's not folder size that you measure, but a user's usage: how many blocks are occupied by files belonging to a certain user, no matter where they are.

That's what quotas are: per-user storage limits.

If Bob has a large file which is sitting in Alice's home directory, that counts toward's Bob's quota, not Alice's. If Bob could sneakily change the ownership to Alice, while leaving the permissions open so he could access the file, then the file counts toward Alice's quota.

Because, in the early days of Unix systems actually being used as multiple, simultaneous, user systems, you might have one group of users collaborating on a project, and they would have a shared directory (via the 'group' owner) where they would store shared items. Each user would create various files, and each file's space consumption was charged to that user, but the shared directory might contain multiple files each owned by different users (but all owned by the shared 'group' identifier, so the group could access them).

For a group shared directory, assigning the disk space usage of files therein to one single user (ignoring the aspect of "which single user do you pick") is unfair to that user (his/her allowed maximum disk space is consumed) while everyone else is not charged for their actual usage.

This all came about to try to enforce rules to prevent one (or a few) rogue users from using up all disk space on the system for themselves, leaving no one else with any disk space available for their own usage.

One reason why Unix quotas are generally not maintained and imposed by path is that it's a lot easier to update quotas as things are created, deleted, modified, and so on if the only thing that matters for who gets charged is some attribute of the inode, which you always have available. This was especially the case in the 1980s (when UCB added disk quotas), because that was before kernels tracked name to inode associations in RAM the way they generally do today. (But even today things like hardlinks raise questions.)

(I'm the author of the linked-to article.)

Suid binaries were a bad idea and should be removed anyways.

It's just a nice security measure.

But imagine if you were the bank-safe owner. Shouldn't you be able to change the lock?