Glyphs 3 allows us to install RoboFab ported to Python 3 and the objectsGS.py wrapper is still viable, but it looks (at least to me) it’s there only for compatibility reasons.
Focusing only on manipulating UFOs, fontParts/defcon/ufoLib2 are the modules that must be installed manually at the moment, but you aren’t going to need them as the Glyphs API can mostly do the same thing.
So, are there benefits to installing RoboFab for Glyphs 3 in case when I don’t have scripts that depend on the RoboFab API or I write a new script from scratch? Should it be avoided unless there is a historical reason to do so?
If you need to ask the question, there is no reason for you.
The robofab layer is only meant to make it easier to use scrips written for other font editors.
For new scripts I would recommend to use the native script API.
Thank you so much for the clarification! As fontParts also tries to be compatible to the RoboFab/RoboFog API (while not 100%), that means simple scripts may work without modification on both of the editors if I’m lucky enough…that’s good to hear 
Yes, for simple scripts it should work. But there are so many things in the Glyphs API that can’t be handled by the fontParts/roboFab API (interpolation, corners, some of the font info) that I would try to avoid using it if possible.
I tried a few times to better support fontParts but never get very far.
Thanks for mentioning the fontParts status as well. I fully understand the situation. I thought RoboFab has been dead for ages, and I tend to choose defcon when I write a CLI script so I became a bit confused why it’s available via Plugin Manager forgetting the fact it was about an abstract protocol between the app and the scripting environment. The compatibility layer is definitely helpful for lowering the bar for scripting even if it’s not 100% perfect.
I’ll have a look, thanks!