I don't think supporting a lot of different hardware is a big factor, but if you think it is, building standardized hardware to your liking is a pretty affordable thing to do today. You can use a highly standardized Raspberry Pi, you can implement custom digital logic on an FPGA, or you can wire together some STM32 or ESP32 microcontrollers programmed to do what you want. Bitbanging a VGA signal is well within their capacity, you can easily get US$3 microcontrollers with more CPU power than a SPARC 5, and old DRAM is basically free.
I think it's probably possible to achieve the level of simplification we're talking about, but as I explained in https://news.ycombinator.com/item?id=43332195, the older systems we're talking about here are in fact significantly more code than they are being represented as here.
L11n message catalogs (.po files, which I think is what your remark about i18n is intended to refer to) are not conventionally considered to contain lines of source code.
You can write a lot of games in not much code, especially when efficiency isn't a major concern. I've made some efforts in this direction myself.
Without a game engine, Tetris is maybe 200 lines of JS http://canonical.org/~kragen/sw/inexorable-misc/tetris.html, 200–300 lines of C (building on the fairly minimal graphics library Yeso) https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/tetris... https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/tetris..., or 300–400 lines of assembly when optimized for small executable size http://canonical.org/~kragen/sw/dev3/tetris.S https://asciinema.org/a/622461. The fairly elaborate curses Tetris in bsdgames (which I didn't write) is 1100 lines of C. Emacs comes with a tetris.el (which I also didn't write) which is almost 500 lines of Lisp.
Space Invaders without a game engine, using only a color-rectangle-fill primitive for its graphics, is about 160 lines of JS http://canonical.org/~kragen/sw/dev3/invaders ; when I factored out a simple game engine to make the code more readable, and some added elaborate explosion effects, it's closer to 170 lines of JS http://canonical.org/~kragen/sw/dev3/qvaders. (These have a bug I need to fix where they're unplayably fast on displays running at 120Hz or more.)
A minimal roguelike, hunting treasures in a colored ASCII-art maze, is 54 lines of Forth: http://canonical.org/~kragen/sw/dev3/wmaze.fs https://asciinema.org/a/672405.
And, though it doesn't quite rise to the level of being a game, a Wolf3D-style raycasting engine with an editable maze world is about 130 lines of JS http://canonical.org/~kragen/sw/dev3/raycast.
I didn't write this, but you can write Pong in JS in Notepad in five minutes: https://www.youtube.com/watch?v=KoWqdEACyLI
Emacs comes with a peg solitaire (which I didn't write) which is under 400 lines of Lisp.
The Hugi sizecoding competition delivered a lot of games that were under 200 bytes of code: https://www.hugi.scene.org/compo/compoold.htm
My experience writing these tiny games is that a lot of the effort is tuning parameters. If Tetris speeds up too fast, it's too frustrating; if it speeds up too slowly, it's boring. If the space invaders drop too many bombs, or advance too quickly, it's too frustrating; if too few or too slowly, it's boring. I spent more time on the explosions in Qvaders than on writing the entire rest of the game, twice. This gameplay-tuning work doesn't show up as extra source code. All of these games significantly lack variety and so don't reward more than a few minutes of play, but that's potentially fixable without much extra code, for example with interesting phenomena that stochastically occur more rarely or with more level designs.
MacPaint, for what it's worth, is about 2000 lines of assembly and 3500 lines of Pascal: https://computerhistory.org/blog/macpaint-and-quickdraw-sour... but you could clearly put together a usable paint program in much less code than that, especially if you weren't trying to run on an 8MHz 68000 with 128KiB of RAM.