A reasonable analogy would be learning to drive.
There exists rules, protocols to follow and standards of quality and robustness in both the car and the driver.
- Cars have a steering wheel.
- Some have a manual gear and some are automatic.
- You (in most countries) drive on the right hand side of a road.
- Signs provide instructions on how to drive on a particular road.
- Units of measurement are (mostly) in km/h.
- The fuel taken in the vehicle is of a certain mix and standard.
- Drivers are trained and expected to follow a certain standard of driving.
Now, you might suggest (I'm not that cultured though and giving myself some poetic license) that European roads are "standards compliant" with one another, such that if you learn to drive in Spain, you can potentially drive anywhere in Europe, potentially with the same car or at least maybe a different car where all the appendages and sticks are in a place you might expect them to be.
You could for example invent an entirely new way to drive, perhaps with totally different signage, that you drive on either side of the road, use a joystick to drive and you measure your distance in cubits per hour, however, migrating to that system from the one you're used to requires a whole boatload of more effort.
POSIX kind of fits a similar model but instead of cars, roads, speeds and destinations its referring to inputs, messaging, programs, outputs and features.
Its generally best (as a programmer and user) to have certain rules governing features/functions and inputs/outputs available to you, so you can perhaps write a program that fits to these standards and then without much effort rebuild the same program to run on a different system, which also takes the same inputs/outputs.
For example the Linux system calls read and write are posix compliant. They take certain inputs, in a certain order and return certain outputs with rules governing what the outputs might be or represent in certain circumstances.
You can write a program on Linux that opens two files, uses read and write to transfer data between them and closes them again. Then potentially go rebuild it to run on a Mac too without having to rewrite the underlying source code.
You can also however do exactly the same operation -- much faster -- by opening two files, using the sendfile system call to move data between them and close it again (unless you're using very very very old kernels). The trouble here is that the sendfile system call is not POSIX compliant -- you cant be guaranteed that such a system call exists properly on the system to do what you want.
In fact, if you check out the Mac man page for the sendfile call, although its called the same operation, it takes a different set of parameters and offers different features (also, you technically cant actually use it to copy from one file on disk to another on disk).
Hence you wont be able to run a program using linux sendfile predictably on a system niavely at least without changing the program or using some other compatibility layer.
This is why people care about POSIX. It avoids reinventing the wheel and potentially permits you to migrate to a better overall 'posix compliant' operating system, or at least, focus on delivering your product rather than worrying about the quality of materials used to build the foundation.
I've skipped much of the whataboutisms of when POSIX isn't really truly followed completely and utterly even by those that claim their system is POSIX compliant, but thats the jist of the concept.
One final point I'd want to make clear. If you code to the lowest common denominator of a standard (like POSIX) you're going to miss out on big performance gains you might otherwise have been able to leverage by using non-standard extensions on the operating system you are coding for.
So its also a design choice, if you're aiming for high performance/high throughput then to achieve that you might not code for POSIX compliance.
Albeit, hiring a programmer who knows how to program 'posixally' (knows how open, read, write pthread and close works in POSIX) is going to be far more straight-forwards than hiring somebody that only programs to some weird unused standard.
So its not just about performance (the cars), but also the adaptation potential (their adeptness at driving the car).
