I believe I have a solution for our needs, which was prompted by this post:

Re: Interact with service portal widget in catalog item

And that this callback in the Client Script for the Form widget:

$scope.$on('spModel.gForm.initialized', function(e, gFormInstance) {

Is also being called for the embedded variable editor. Provides a scriptable location that has access to both the form fields and variables.

To make use of this I've created a custom Form widget where I added a CustomEvent fire which provides both field and variable g_form objects to observers:

var g_form;

$scope.$on('spModel.gForm.initialized', function (e, gFormInstance) {

       if (gFormInstance.getTableName() == $scope.data.f.table)

               g_form = gFormInstance;

       // Trigger an event to indicate variables are ready

       if (gFormInstance.getTableName() == null) { // Is there a better test for here?

               CustomEvent.fire('soton.variable.ready', g_form, gFormInstance);

       }

});

Then in the sc_req_item Client Script I've added an observer that will apply our variable read-only policies (and as a Client Script also has access to g_scratchpad, which the variable editor doesn't):

CustomEvent.observe('soton.variable.ready', function(g_form, g_variable_form) {

I can then perform operations over both the fields and variables e.g.

if (g_form.getValue('state') == -6) {

       g_variable_form.setReadonly('comments', true);

}

Note that g_variable_form - the g_form object on the variable editor - refers to variables using their name and does not expect a "variables." prefix.

In the many dead-ends I've gone down with this I've noticed that the Form widget and its g_form knows about variables but the Service Portal g_form class seems to be missing the equivalent functionality for handling variables that exists in Platform i.e. you can call a g_form function with "variables.{variable name}" and have it work on the variable.