Done on ‘Rhino 9 Beta 9.0.26216.12303’ even without any plugins. (And does not happen on Rhino 8).
How to recreate it: Open Rhino, open options. (i have a bind, but you can click or cmd it). Close it, reopen it. Watch your ram go up very fast. (Just check process manager). If you’re fast you can leak 1.5GB in 30 seconds 
I did some dumps with dotnet-gcdump (taking a dump forces a full GC), but all this stuff was still alive afterward, so it’s not just Rhino delaying/not doing cleanup, the live heap went from:
47,400,599 bytes aka 501,043 objects
INTO
687,479,900 bytes aka 10,000,000 objects (could be hitting the dump limit of dotnet-gcdump)
The types include stuff like:
Rhino.UI.Internal.OptionsPages.OptionsPageHost: 0 -> 2,170
DisplayAttributesOptionsViewModel: 0 -> 2,412
Eto.Wpf.Forms.EtoBorder: 135 -> 70,545
Eto.Wpf.Forms.EtoGrid: 68 -> 40,091
WPF mouse-button event handlers: 724 -> 292,954
WPF routed-event-handler lists: 2,633 -> 779,043
At first i thought it was the Alias menu as that one opens painfully slow, like multiple seconds per time, but no it happens with the same “degree” on all menus no matter what. I tried with my extension as well, which opens its own Eto element and options menu thingy, and that didnt do it (the GC got whatever it made).
Same with other UI elements in rhino i tried out, clicking on the side panels etc sub menus. seems to work fine.
So ye if you do it, rhino becomes slow, and you notice it quite quickly in my opinion. I’ve even experienced getting white Eto dialogue menus/boxes.
TLDR: Rhino 9 UI/Eto leaks around 50Mb memory every time you open up options. Probably something like every ‘Options’ call creates a new collection of ‘OptionsPageHost’ objs and a shitload of Eto/WPF visual trees/bindings/eventhandlers or structures. Something keeps those guys around after the user closes the window.