First off it is good to use the ParameterAttachments for the GUI updates. It makes no difference if you use the AudioProcessorValueTreeState and the Attachments in there, or if you use the ParameterAttachments that work without the APVTS.
The if branches in the parameterChanged() callback can and should indeed be avoided.
For the issue that it’s not updating, there are some caveats that might make the update seemingly not to work, e.g. a ComboBox, if it has no choices at the time of creating the ComboBoxAttachment will reset the value because the initial update failed (you cannot set the ComboBox to anything else than the 0).
In the audio processing it is indeed advisable also not to use the ParameterAttachment, since they are designed to interact with the GUI thread. I haven’t checked, but some things might introduce asynchronous steps that are only good for GUI updates.
Instead you use the atomic value in the parameter. One way is to use the getRawParameter("paramId") as described above (but please keep the returned atomic<float>* param as member to avoid any overhead.
The better way (IMHO) is to keep a pointer to the actual parameter (again keep it as member):
// as member
juce::AudioParameterChoice* oscNumber = nullptr;
// in constructor
oscNumber = dynamic_cast<juce::AudioParameterChoice*>(getParameter ("paramId"));
jassert (oscNumber); // if this fails there is no parameter with this parameter ID of type choice
// use it
auto currentOsc = oscNumber->getIndex(); // is the correct type, no lookup and thread safe
Hope that helps