On this, see comments by @jacobwilliams here (“Make it a class and put the work arrays in the class”) and here ("… the object-oriented interface is the real one…").
Should one pay heed to the deprecation by the authors of MFE of the feature mentioned in the original post, an OO approach would make sense. And indeed it’s a pattern preferred in some domains, particularly in industry whereby consumers never directly allocate and use work areas such as worka, workb1, workb2 or deal with pivots, to state the obvious they navigate at a high level using helper procedures for the same (usually type-bound) that do the needful in terms of setting up the components of the derived type (the class) suitably and the method invocation to do some work is always with the same i.e., with a consistent API, say
call process%work( x ) ! or call work( process, x )
Thus making the feature in question inoperative.