Perhaps because the names of files and directories are generically known as "filenames" in the unix world.
Not knocking you for this, but it's equivalent to Anonymous Monk's "Because", perhaps funneling into Appeal_to_tradition. But seriously, I understand, "FILENAME" here may be a generic term for any named filesystem entry, whether it's a file, link, directory, device, pipe, etc. But mkdir will only make directories, so let's be clear and specific, when that doesn't compromise generality. "mkdir DIRNAME" will in no way cause anyone to misunderstand what will happen.
On the other hand, if there's some great savings in coding so docs and parsers and grammars don't have to handle special cases between things like chdir, mkdir, open, do, require, rmdir, chroot, link, symlink, and other things that take named filesystem entities, I'm all ears. I'm sure the developers have enough to do besides handle pedantic observations like this.
Whoops! See rmdir:
Deletes the directory specified by FILENAME if that directory is empty. If it succeeds it returns true; otherwise it returns false and sets $! (errno). If FILENAME is omitted, uses $_ .
To remove a directory tree recursively (rm -rf on Unix) look at the rmtree function of the File::Path module.
And chmod and chown look weird, just specifying a list. For example:
when the detail says the first element must be the mode. This is better written as:
chmod MODE, LIST
Quantum Mechanics: The dreams stuff is made of