I somewhat agree.
(Edit: Moreso that the library isn’t designed to be able to output to another kind of display than on the idea of attempting to scale existing games to work in portrait mode.)
I’ve actually considered this scenario in the past when working on a few attempts to create a prototype ‘version 2’ of the library.
I came to the conclusion that the best solution is to separate ‘display modes’ (which draw to a buffer), from the actual output device, which normally would be the internal screen but could also be some other device.
E.g.
HighRed16ColourMode graphics;
Display display;
void render()
{
graphics.drawLine(x0, y0, x1, y1);
// 'draw' would be templated to accept different
// classes providing the same API.
draw(graphics, display);
}
I eventually gave up on my attempts, partly because (like yourself) I found it hard to make sense of how to set up and drive the hardware, and partly because I was unsure whether the effort was justified.
I agree.
When I was creating the Arduboy2 port (which I never quite finished) people kept asking me to implement scaling, but the fact of the matter is that scaling to fit a screen with a different aspect ratio always creates distortion and it can often be very ugly.
It took some digging, but here’s an example image:

And here’s three different scaling algorithms:

None of them look as good as the original.