Haha, that's probably an electron app. Or they use a really buggy UI framework. Otherwise, I wouldn't know why updating a 4x8 pixel block would cause a significant amount of power usage. Especially if a 286 could do it no problemo.
This is actually more noticeable for efficient apps than inefficient/bloated apps as the latter don't get as many chances to enter deep idle states in the first place.
There's a considerable difference in doing that once a second and dozens (hundreds? thousands? depending on how it was implemented) times a second, which I would assume what the previous default ("smooth") setting meant.
There are ways around it, but it requires direct interaction with the compositor, which while supported by the APIs, it's more complicated.
So evolution. Does this mean that a laptop with lower screen resolution has better battety life ? It explaines why Win 10 is so crappy with screen and cursor updates.
It's true whether it's a terminal emulator, a browser or an office suite.
GPU power saving loves static content (OLED screens don't, but that's another story)
If using the API's correctly, the compositor can be limited to only updating a small part of the screen. If really only switching the cursor between on and off, that'll happen roughly once per second. And lastly, the whole thing can be skipped completely if the cursor happens to be invisible, for example if the editor is minimized or (partially or fully) obscured by other windows.