If you can't see why it's a bad idea for both security and usability to have two different, conflicting sets of permissions for the same data, then I can only say that I'm glad you probably don't have any influence on this issue. Consider the case of restricting write access to a file: you would need to know about, and have write access to, _all_ the directory entries referring to that file, as opposed to just a single inode in the current model.
That goes double for the idea of banning hard links, which are actually quite useful and logical given the separation between human-readable names and inodes. In any case, without hard links there is no motive for moving the permission bits to the directory entry, as you suggest, since the mapping between directory entries and inodes would be one-to-one. Only the case with hard-links is interesting in this context.
The filesystem permissions apply to inodes and not directory entries for a reason, and once you replace the limited owner/group/other model with POSIX ACLs, the system works rather well as-is. It's only the Windows-style permission model which has issues relating to inherited ACL.