POSIX is clear in https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html that the dirname(3) function returns a non-empty string for input of "/".  However, POSIX is also clear that the string composed by 'dirname(str)+"/"+basename(str)' need NOT refer to the same file as 'str'; case in point: when str is "//", POSIX says you could end up with any of "///", "////", or "/////" depending on choices made in basename and dirname, but all of those results are equivalent to to "/" while POSIX is explicit that "//" may be distinct from "/".

Similar arguments can be made about the behavior of the basename(1) utility.

However, since -printf is not defined by POSIX, there is no requirement that %h be defined by the POSIX functionality of basename(3) (the function), nor of basename(1) (the utility).  However, if we intend to return the empty string, it IS a bug if our documentation is not explicit that we intentionally differ in behavior from the POSIX functions, and give examples why we think that is the right thing to do.

There is also a case for having the empty string there. If it was the case for %f as well, that would mean that -printf %h/%f would always be equivalent to -printf %p

More importantly, in cases like:

find / -name foo -printf '%h/bar\0' |
  xargs -r0 cmd

that means you don't get an incorrect bar when foo is found in /.

Remember that foo is not guaranteed by POSIX to be the same as /foo (and in practice is not on some systems like cygwin).

The :h and :t history modifiers of tcsh and bash (not zsh) do return the empty string for /