This is only a problem if an application or library brings its own HDF5 as a shared library, without shared library name or symbol mangling.
ITK and VTK behave well - their HDF5 will not clash with anything (other than potentially another ITK and VTK), unless you force using “system” HDF5. If you force ITK or VTK to use "system HDF5 then it is entirely up to you to manage version conflicts.
I’ve checked the wheel files of netcdf4 and h5py.
netcdf4 behaves well - it links HDF5 staticallly, so there are no conflicts.
h5py is messed up - it includes shared libraries with non-mangled names (hdf5.dll, hdf5_hl.dll, and even a zlib.dll). This can crash any application that uses HDF5 or zlib. An application or the system may provide a common shared library without name and symbol mangling, but a Python package must never do this (they must not dictate an application what HDF5 it may use). I would recommend not to use this package (or maybe build it yourself, as a static build, if that is supported).