You're half wrong.  FortranFile can read arrays written as above, but it sees them as a single real array.  So, with the attached Fortran program::

In [1]: from fortranfile import FortranFile

In [2]: f = FortranFile('uxuyp.bin', endian='<') # Original bug was incorrect byte order

In [3]: u = f.readReals()

In [4]: u.shape
Out[4]: (20,)

In [5]: u
Out[5]:
array([ 101.,  111.,  102.,  112.,  103.,  113.,  104.,  114.,  105.,
       115.,  201.,  211.,  202.,  212.,  203.,  213.,  204.,  214.,
       205.,  215.], dtype=float32)

In [6]: ux = u[:10].reshape(2,5); uy = u[10:].reshape(2,5)

In [7]: p = f.readReals().reshape(2,5)

In [8]: ux, uy, p
Out[8]:
(array([[ 101.,  111.,  102.,  112.,  103.],
      [ 113.,  104.,  114.,  105.,  115.]], dtype=float32),
 array([[ 201.,  211.,  202.,  212.,  203.],
      [ 213.,  204.,  214.,  205.,  215.]], dtype=float32),
 array([[ 301.,  311.,  302.,  312.,  303.],
      [ 313.,  304.,  314.,  305.,  315.]], dtype=float32))

Awesome!  The thoughts banging around in my head right now are that some sort of mini-language that encapsulates the content of the declarations and the write statements should allow one to tease out exactly which struct call will unpack the right information.  f2py has some fortran parsing capabilities, so you might be able to use the fortran itself as the mini-language.  Something like

spec = fortranfile.OutputSpecification(\
"""real(4),dimension(2,5):: ux,uy
write(11) ux,uy""")
ux, uy = fortranfile.FortranFile('uxuyp.bin').readSpec(spec)