That is to say, I don't think people are using Unity because they were mistaught by complexity loving professors.
I wonder if this kind of architecture might also be a pretty good approach. The fact that they were able to port the game to another engine within a day is pretty impressive.
I've never played the game, but my understanding is that Slay the Spire largely impresses on a design and artistic front, not a technical one. Its engine requirements were not based on feature set or code quality, but on what developers knew. So they probably picked Unity because it was ubiquitous. Education starts the problem, and then devs who need something common they care hire for continue the problem. I don't blame devs for this, it's the right choice to make and obviously Slay the Spire is great, but I am saying that this is a force that drives down the quality of game engines.
Being ubiquitous was part of the decision, yes, because it means there are many high quality plugins instantly integratable which is a huge time-saver.
You are correct: I definitely agree that not all gamedevs should be making stuff from scratch, but I also think that Unity is a little too much. There's a good middle ground somewhere slightly above raylib.
My argument is that the promotion of engines that live near this middle ground is blocked by education: people who want to be able to sell long courses to the people who look up "how to make a video game."
But also features this brief comment on game libraries:
"More than a Game Library: Having worked in SDL and LWJGL I’d like a bit more handholding. A few in-house APIs for loading/unloading resources, font stuff, and display handling please. I don’t want to write those; I want to make games!"
and some words on LibGDX in specific
"The reason we chose LibGDX for Slay the Spire was because it could do PC, Mac, and Linux. Yes, it runs in a JavaVM and it has all sorts of problems but it’s write once, run anywhere amirite? No. It don’t run on consoles and Mac and Windows updates constantly break it. "
All that said, I still love LibGDX, raylib, löve, and if I was going to make a game I'd use one of those because I think they're more fun. But I'm also not doing this professionally, on a deadline, and with a requirement to work on consoles
But yeah, the more cards there are on the screen at once, the lower the framerate gets—very noticeably so, when you're e.g. looking at the view of your entire deck, or when you draw several cards at once. I just assumed it was some inefficiency that entirely unnoticeable on a high-end PC (250+FPS, no problem), but was very apparent on the Switch. I never would've guessed there would be something far crazier at play than I imagined!