How does 'everything is a file' not contradict 'do one thing and do it well'?

Not only there is no contradiction—both go the same way.

“Do one thing and do it well” encourages composition over monolith. For instance, instead of having one huge application that makes it possible to create videos and also encode them and handle all sort of video devices such as video cameras, one could have a GUI for creating videos, and this GUI will rely on a separate program that deals exclusively with video encoding, and a separate program that handles devices and presents a video camera as a stream—in other words, a file.

The benefits of such approach:

1. Programs are smaller, and therefore easier to maintain.

2. A user may only be interested by video encoding. No need to install the whole monolith to do just that.

3. Parts of the system can easily be swapped, and alternatives can be created more easily than when trying to create the whole monolith.

“Everything is a file” is a convenient way to achieve “do one thing and do it well.” Think of it as a standard.

Consider electricity at home. In your country, there is very likely a standard for wall sockets. In a socket, you can plug your PC, or a phone charger, or a desk lamp, or a vacuum cleaner.

Does the fact that one socket supporting all those appliances mean that it's doing too many things? Well, not really. It does one and one only thing: it powers stuff you plug in it. If there were separate plugs for vacuum cleaners (preferably each manufacturer would have its own “standard”) and other ones for your PC (Dell PCs won't go in sockets designed for HP!) and different ones for chargers, and then there would be ones for CFL and ones for Osram LEDs, and ones for Philips LEDs... each socket won't do less compared to a standardized one. It would have the exact same role.

Same here. A file is just a standard by which components of a system may interoperate.

Everything isn't a file. Everything exposes an interface that works as if it was a file.

So all the bits "do one thing well" but they all can be used the same way. A bit like all the tools in your tool box having handles that work with human hands, even though the business end is different.

This is a false dichotomy. There are following options:

• everything is a file
• do one thing well
• do not work at all on a general purpose OS.

File is an interface (one of) of an general purpose operating system that establishes a bridge between drivers (filesystems, IO devices, network) and user space programs (editors, messengers, music players).

It is a limited and arguably not very universal interface. Unix saying "everything is a file" is a lie, in a sense that operations that it allows to do over a file object are by no means file-like. Unix can send datagrams over file, listen for them, execute a broad set of esoteric commands like "write data and wait for an hardware interrupt".

Windows separates un-file-like operations better, by providing other types of OS handles (sockets, pipes, ports). It still gives some file-like operations to those though.

There is indeed an inherent contradiction between an attempt to implement generic interface for disparate entities and make it work well for a single task.

The current situation (Unix adding strange operations over files and Windows supplying some file-like operations on non-file devices) is the result of a compromise. Too narrow of interface would shift complexity from device driver to user space programs. Too wide interface would shift the complexity the other way. Imbalance would cause one or the other to die out. General purpose OS is tasked with balancing things out, hence suboptimal, but universal solutions.

To really understand how the conflict is resolved, one has to look into real-time or specialized or embedded OS implementations - there compromises are resolved in a different way because no priority is given to broad application of an OS.