> And it's not quite unlike the current situation - you must have +r access to file's directory to be able to read it (if you obtain the file handle to it by doing path traversal).
The current situation is that you need read permission to a directory to read its directory entries (e.g. with ls), and search (+x) permission to access files and directories under it. The two are orthogonal; you don't need read access just to traverse a directory, and you don't need search permission just to list the contents.
You also need read access to the individual file to access the file's contents, and typically _that_ is what you want to protect. The read and search bits on the directory govern access to the directory (listing and traversing), while the permission bits on the file govern access to the file's contents.
In the common case of one directory entry per file, there is no difference between your proposal and the way the system already works. Each file would still have one set of permissions, just stored in the directory entry rather than the inode. However, in the case of a file hard-linked into multiple directories, a single item (the contents of the file) would have multiple, possibly conflicting, permissions, depending on the directory entry used to access it. I consider that a step backward from the current model of one clear-cut set of permissions per filesystem object.