I guess it’s about entropy. Some items have more entropy than others. They have more parts and more possible states, and most of those states are misconfigured.
A table or a chair has most of its parts glued together in a fixed, low-entropy position, and has few parts to begin with.
A printer has many parts, both at the hardware and software level, and they can be in many states. It has paper, which can be in a state of having run out or not, and if it has run out, the supply can be almost literally anywhere. It has many intricate mechanical parts which can wear out at different rates, it has an ink cartridge that can dry out even when unused, and many intricate little parts that I don’t even know about.
On top of that, the software also has high complexity. Lots of software components, including the low level stuff that manages the actual printing, whatever needs to connect to the wifi, whatever is needed in case it can print from email, etc. all of these processes can run concurrently, which may introduce race conditions, any of these components may have a bug.
And then there’s the drivers installed on your laptop, which may be out of date, or your laptop’s drivers may be fully up to date but the printer software is out of date and your driver is no longer compatible with it.
Many components, many possible states, high entropy.
EDIT: also, I think a big part of it is that printers aren’t really tested for reliability. I used to work at a car manufacturer. Cars are hybrid software-hardware systems, and both sides of that equation are highly complex. Car engineering is a huge discipline that focuses aggressively on reliability. Even though car makers appear to come out with a new model every year, in reality they only change the cosmetics. The underlying platform usually only changes once every six years, and every version of the platform is aggressively stress tested in every possible way. The company I worked for had a test track in the coldest possible part of Canada, as well as in Death Valley, because reliability testing has to be aggressive and thorough.
Also the software side used special, hardened compilers that only supported a subset of the programming language, and were rarely changed. Getting a contract to supply a car company with a critical tool like a compiler is a hugely profitable multi-year deal, because they are happy to pay for reliability and reluctant to change something that is working well.
I bet nobody really cares about the reliability of printers to the same extent, and they have huh entropy, so they generally suck.
Actually I wonder if we could do an experiment in the following way:
Collect Wikipedia in English
Collect Wikipedia in some other language, e.g. Japanese
Train an LLM on these two languages
Try it out!
It’s true that there will be some amount of overlap, but this should put a ceiling on how well this approach could work.