Not necessarily. I did a quick conversion of the Calculator Textual example to Lazarus' LCL and if anything Textual seems to be using more memory[0] (i did use the PSS as a comparison - ideally i'd boot into a VM running a minimal Linux distro to avoid any interference by background stuff like systemd, etc and record the free memory before and running each one, but i don't want to spend that much time on it and PSS is a decent approximation for how much memory a process that shares memory with other processes would need).
Note that i only converted the UI, i didn't implement the calculator logic but that shouldn't make any practical difference.
Lazarus (LCL actually) is a very big framework that sits on top of a toolkit (Gtk), it is already way far removed from Xlib or Win32 (and is certainly heavier than what it could be :-P).
I'm not sure what you mean with "oldschool", if anything working with something like Qt or Gtk directly where you either specify the UI by manually creating widgets/objects or by using a separate UI editing program (that often only has a fraction of Lazarus' features) that only edits an approximation of the UI and stores it in what are essentially resource files (not very dissimilar in concept to the Win16 resource editing tool) is a bit more old-school in my mind (Lazarus on the other hand edits live objects that are serialized to/from disk, which incidentally is kinda similar to how -e.g.- a modern game engine like Unreal works... though Unreal's UI toolkit is worse than any of Qt/Gtk/etc combined :-/).
The Python lib most likely needs more optimization, but my point was that a TUI program can still be more heavyweight than a GUI one (the original question about why rendering a GUI in a terminal after all).
I'd agree if you only referenced Electron, but you also referenced other GUIs :-P.
