IIRC TIS-100 is implemented using Unity, which doesn't really give you a lot of leeway as to when you update and render (e.g. you choose a framerate and it renders and updates your objects at that rate). Admittedly, since most of the time in TIS100 the screen does not change, if it were implemented using a custom engine this could be fixed.
For desktop dungeons, I'm not aware of the specifics about that game (though I have played it), but generally, if you're using OpenGL or DirectX to render, repainting only part of the screen isn't an option, so if anything is animated (no matter how slight the animation), you have to redraw the screen every frame. There are exceptions to this (like the mouse pointer, although this requires platform specific code), but not many of them.
As I mentioned in the other comment, perhaps the problem is poor Linux support on the Unity side of things? Which would be... how shall we say... typical, since Unity also targets mobile platforms. You'd think they'd allow developers to properly optimise for fan noise.
Regarding DD: first, it's also implemented in Unity, so... but that aside, even if the whole screen gets repainted, it shouldn't max out. The graphics are just not demanding enough for that.
Well, repainting at 30 or 60fps is going to heat up a lot of computers, demanding graphics or not.
Although you're probably right that it's mostly a Unity Linux support issue. My understanding is that Unity Linux support is mostly a labor of love from the Linux-using employees at Unity, and that it doesn't get a lot of attention other than that.
For desktop dungeons, I'm not aware of the specifics about that game (though I have played it), but generally, if you're using OpenGL or DirectX to render, repainting only part of the screen isn't an option, so if anything is animated (no matter how slight the animation), you have to redraw the screen every frame. There are exceptions to this (like the mouse pointer, although this requires platform specific code), but not many of them.