This is really an issue of how loaders search through object libraries. The fortran standard text quoted above is a separate issue; namely that once the block data name has appeared in a program unit, then it means that intrinsics and other external functions cannot use that name in the same scope. The standard does not address how the object files are managed (by ar on a posix system) or how the loader (ld on a posix system) searches that library to resolve its external symbols.
In the 80s I programmed on vax vms, a variety of unix systems (bsd, system v, and hybrids), and several other OS types (such as ibm mvs, dec tops-10 and tops-20, univac EXEC 8, cray COS, cray CTSS, harris VOS, data general AOS, and probably a few others). They all seemed to work a little differently and they all had their quirks. One of the features that I remember about the vax system was that you could compile a fortran file with several subroutines, and when that file was added to the library each subroutine was its own entry, as if it had been compiled alone in a file and added to the library just by itself. The nice feature of this approach was that when you linked to make the executable it would only extract the subroutines that were actually referenced and needed by the program, giving the smallest executable files – memory then was a precious and limited resource. I think the same thing would occur for a function or subroutine declared as EXTERNAL but then not actually referenced in the program, the linker would eventually just ignore it. I remember there was a flag where you could tell the vms linker to load a particular object file even if it wasn’t referenced. Maybe it was /force=name or something like that? I think that option was specifically for things like fortran block data that might not be loaded otherwise (since there was not a function reference by that name in the program to trigger its inclusion).
On the other hand, the unix/posix systems did not do that. They all seemed to create a single object file for each compiled file that was thereafter treated as a single entity within the object library. If any single function within that file was referenced, then the whole object file was loaded into the program. There are both advantages and disadvantages to this approach compared to the vax approach. For example, it sometimes resulted in larger executable files than necessary since unused and unreferenced functions were loaded into your program. But on the other hand, it solved the block data program because you could compile the block data in the same file as another function, and if that other function was grabbed from the library by the loader, then it would also pull in the block data.
I remember organizing files in vax vms so that I had dozens of related subroutines in each file, so even a large program might end up with only few dozen files. Then when porting to unix machines, I would fsplit those files to edit/ar/ld each subprogram separately. Then when f90+ came along, I regrouped those separate related files into modules, arriving back at something like the earlier vax vms organization.
Another approach back then was to not include the block data into the library, but rather load its object file directly. Another useful approach was to include the block data into the same file as the main program, and then when the main program object file was loaded (usually directly, not from a library), it would pull in the various block data units along with it.
In all of those operating systems I used back then, there was always some kind of workaround for fortran block data. Of course, other languages often have similar features with different names, initialized data that must be loaded into the executable, so this was not just a fortran issue, but also an issue with many other languages, including the various assemblers on all of those machines.