The code is the same regardless of the 1 header file or 2 headers and 2 source files approach used. The AudioPluginDemo code has the oddity that the GUI editor class is nested inside the AudioProcessor code, but that doesn’t change anything either. (It’s just about how the classes are declared, but they would still be used the same way in the Projucer generated projects that have the 2 header files and 2 source files.)
The reason you are not seeing much communication code in the examples may be because they are written in a way where that isn’t needed. For example the AudioPluginDemo uses AudioProcessorValueTreeState and AudioProcessorValueTreeState::SliderAttachment to get the sliders to change the AudioProcessor parameters. They also automatically change their positions if the host automates the parameters, thanks to the attachments.
It may be none of the Juce provided examples no longer use the old fashioned way to deal with the parameters and the GUI components, where one would explicitly need to set up slider listeners to change the audio processor parameters and use a Timer to update the slider positions when the parameters are automated.
The Projucer generated plugin projects naturally don’t have any processor<->GUI communication code, apart from passing the reference of the processor object for the GUI editor. It’s up to you to add parameters into your plugin processor object and come up with some way to connect those to the GUI. AudioProcessorValueTreeState and the component attachments are probably the easiest way to do it currently.