Thanks, @keith.
“Sandboxing” custom plug-ins in some way, shape, or form is certainly understandable given the havoc a rogue plug-in could wreak with the editor environment (intentional or not).
But yeah, I agree. The current implementation is far from ideal. It sure seems like there should be a way to reuse code from the initialize() and/or update() functions. 
If you’re referring to this issue (further described here), then yes, I can confirm it was indeed eventually resolved. 
Yeah, that’s it in a nutshell. I’m hoping it’s just an oversight - a line of code the dev team overlooked to make fonts available to the plug-in preview.
However, I can also understand the need to keep the editor as lightweight as possible, and it’s easy to see how loading anything but the bare essentials into what amounts to a separate web page for each custom plug-in could adversely impact the whole editing experience.
That said, I guess I’ll try loading the fonts myself. 
And oh yeah, as a side issue, have you noticed that the font_face property is made available as “Barlow Semi Condensed:::100italic” where the name of the face and its variants are separated by 3 colons? That format is unfamiliar to me, although it’s easy enough to parse.
EDIT: In fact, when I discovered this, I was certain that was the reason the font wasn’t rendering properly, as I was initially just assigning that value to the CSS property of the same name! But even after parsing out the font-face property and assigning only that, still no joy.