mount(2) required the creation of a new directory to be the mount point, you couldn't mount anything under a read-only filesystem. That would be dumb, so we can rule that out.
If mount optionally created a new directory to be the mountpoint, that would be weird. It's not like mount/unmount happen all the time, so putting extra logic in the kernel to do these two steps with a single system call would not be an important speedup. Just leave it up to user-space to make a
mkdir(2) system call if it wants one. Dmitry's answer points out that having
mount(2) do both things would make it non-atomic. And you'd want an extra argument to
mount(2) with mode flags like
open(2) takes, for
O_EXCL, etc. It would just be silly compared to letting user-space do it.
Or maybe you were asking about having
mount(8) (the traditional program that makes
mount(2) system calls) do this? That would be possible, but there's already a perfectly good
mkdir(1) for the job, and Unix's design is all about good small tools that can be combined. If you want a tool that does both, it's easy to write a shell script to build that tool out of two simpler tools. (Or, as muru commented,
udisksctl already does this, so you don't have to write it.) Also, Linux's normal
mount(8) from util-linux supports
mount -o x-mount.mkdir[=mode] using it's
x- syntax for options for userspace, rather than options to be passed to the filesystem.
Now the more interesting question: why does there have to be a directory on the parent filesystem at all?
Like pjc50's answer points out (no relation, even though he has my initials!) , having mount points show up in directory listings would then require an extra check on every
Having mount points exist as directories in the directory containing them (on the parent FS) is a nice trick.
readdir() doesn't have to notice that it is a mount point at all. That only happens if the mount point is used as a path component. Path resolution of course does have to check the mount table for every directory component of a path.