The last part is sort of true, but there's a lot of ways for changing expectations to sneak in. The software often isn't designed for it, so it's hard to model what actions you can take and what you can't before “oops, please connect to the Internet to continue”. And once you've done that a single time, all your previous guarantees are instantly invalidated, because there's going to be a dozen unskippable updates and stuff happening in the background and so on and so on—or you can try to handle that by doing something even more awkward like moving the data off, then factory reset, then updates, then disconnect, then move the data back and hope for the best…

That said, this is something I did with a cheap laptop for a while—installed a basic Linux and Emacs and used it as a mostly-isolated Emacsing machine; I believe I never hooked it up to the network again, though I did sketch out some provisions for manually physically disconnecting sensitive filesystems in case I needed to do that very occasionally (while being aware that sufficiently clever malware could still work around this). But then the logic board malfunctioned much sooner than I'd expected, and I haven't been in a position to get another since.

And 100% air-gapping is not always desirable. Many 1990s-and-before machines that had networking capabilities were still the epitome of “local first” by comparison to the “deployment is primarily done through progressive Web apps” world of 2021. So you could have a few channels by which to talk to the outside world, but without the outside world getting its hooks deep inside you in the process: the television without the telescreen. (Security issues aside, of course—though some of that is mitigable with restrictive proxying, simpler protocols, etc. depending on how retro and how networked you are trying for.)