execute permission on files, meaning here non-directories, is a special variant of read. a file with mode 0111 can be opened with OEXEC and read(2) will work as well as exec(2),
but can't be opened with OREAD, because it's not got any of 0444 set. bits 0111 distinguish a file with contents that are intended to be executed once read from files with only 0444 that do not contain executable content.
you wouldn't want every readable file to be executable (especially if you've used systems that didn't have that distinction).
on the other hand, in a distributed file system, the client needs the contents of the file to run it (whether code or #!script) so it needs to be able to read files with just OEXEC.
I suppose the rule could have been that it would need mode 5 (r+x) to make clear that the file was also readable, but it isn't.
that OEXEC allows reading isn't true for a directory because exec means "search", so if it's mode 0111 (say) you can chdir into it but not read the names within it.
if you know a name of a file in that directory, though, you can still open that. that's entirely enforced by the server.
as the bug in access(2) suggests, only the server knows whether access should be granted, and the open call gets it to do that,
but it doesn't work for OEXEC for directories as others have noted. perhaps stat+chdir is the most accurate test, since you need x (search) permission to walk(5) into a directory,
but the caller won't thank you for the chdir (and there's no easy or certain way back), and ... that restriction isn't enforced by fossil or ramfs. (ramfs wrongly allows you to read a directory that's mode 0.)
probably the best thing is just to ignore the owner/group/other distinction, and if the open(...OEXEC) fails, dirstat it, and if it's a directory with any of 0111 set, it's fine (a little better than now).