The function call is in AudioProcessorParameter not APVTS, so it doesn’t need APVTS to work. I’ve pleaded this case for awhile but you won’t be able to avoid AudioProcessorParameter forever . 
This is because I have been informed that the APVTS parameters are not sample accurate so changes to these cannot be relied on to happen at a specific time.
That’s an issue with the JUCE plugin wrappers, not APVTS. I can think of a way to fix the limitation without drastically changing the abstraction but the only thread safety concerns would be to post a message to the message thread when a real time parameter change is present in the audio callback to update listeners. Since under the hood the only thing changing in the audio callback is the POD type for the parameter, it should be safe to access even if it’s a little outdated. Copies might help if you’re displaying parameters somewhere, for example smoothing them in a meter or something.