Why do we need to compile for different platforms (e.g. Windows/Linux)?

This is like saying if I use the same alphabet all books are the same a Biology text book and a Math text book are identical because they use the same alphabet have a cover have some pages, etc. Or I have to ski resorts and because they both use the same alphabet and because they both are about snow that their posters and brochures are identical.

int main ( void )
{
    return(27);
}

0000000000402cd0 <main>:
  402cd0:   48 83 ec 28             sub    $0x28,%rsp
  402cd4:   e8 d7 e9 ff ff          callq  4016b0 <__main>
  402cd9:   b8 1b 00 00 00          mov    $0x1b,%eax
  402cde:   48 83 c4 28             add    $0x28,%rsp
  402ce2:   c3                      retq   

  00000000004003e0 <main>:
  4003e0:   b8 1b 00 00 00          mov    $0x1b,%eax
  4003e5:   c3                      retq   

subtle differences sure, but the key is that these are two completely different operating systems, the entry/exit of the program (there is a TON of code not shown above that varies, not just the wee bitty spec if main code in this program.

These are different operating systems, they have different calls different rules, they are different, the instruction set being common is somewhat irrelevant. Its like saying because I am running on linux and using C as my programming language then a binary made for arm and a binary made for x86 should be identical and compatible (because two of the three things I said were the same, programming language and operating system but not instruction set. or in your case programming language and instruction set but not operating system.)

This goes so far as to point out that a gcc compiled program for windows is not completely compatible across all versions of windows, you cant just say "windows". same goes for linux. they change within themselves independent of target, then there are incompatible differences between the operating systems. Just because the brick and mortar are the same doesnt make two identical buildings.

This is the purpose of JAVA and Python and such languages, to draw a line everything above this line is common and cross platform, what is below this line can be platform and target specific and no reason to expect any form of cross platform compatibility. Those languages wouldnt exist if we had this kind of compatibility across the world of computers with C compilers or computers all running linux independent of platform or all running an operating system with a compiler and the same instruction set.

There is a reason when you go download some program like chrome or 7-zip or firefox, handbrake, etc there are different installers and/or binaries based on the operating system, and operating system version. The instruction set is often not even listed as it is assumed to be x86, yet there are different binaries, if it were this trivial then why would those folks who have delivered finished products for so long be delivering several different builds of the product?

Even though CPU is the same, there are still many differences:

• Different executable formats.
• Different calling conventions might be used. For example Windows x64 passes integer args in different registers than the x86-64 System V ABI and has several other significant differences, including call-preserved xmm6..15 in Windows, unlike other x86-64.
• Different conventions regarding stack structure. Some systems have a concept of "red zone" to help compiler generate shorter code. Execution environment has to honor such concept to avoid stack corruption.
• Programs are linked against different standard libraries with different ABIs - field order might differ, additional extension fields might be present.
• In both C and C++ some data types have OS dependent sizes. For example on x86_64 long is 8 byte on Linux, but 4 bytes on Windows. (Type sizes and required alignments are another part of what makes an ABI, along with struct/class layout rules.)
• Standard libraries can provide different set of functions. On Linux libc provide functions like snprintf directly, but on Windows snprintf might be implemented as static inline function in a header file that actually calls another function from C runtime. This is transparent for programmer, but generates different import list for executable.
• Programs interact with OS in a different way: on Linux program might do system call directly as those are documented and are a part of provided interface, while on Windows they are not documented and programs should instead use provided functions.
• Even if two OS rely on program doing system calls directly, each kernel has its own set of available system calls.

Even if a Linux program only calls the C library's wrapper functions, a Windows C library wouldn't have POSIX functions like read(), ioctl(), and mmap. Conversely, a Windows program might call VirtualAlloc which isn't available on Linux. (But programs that use OS-specific system calls, not just ISO C/C++ functions, aren't portable even at a source level; they need #ifdef to use Windows system calls only on Windows.)

• Not OS related, but programs compiled by different compilers might not be interoperable: different standard libraries might be used, things like C++ name mangling might be different, making it impossible to link libraries against each other, C++ exception implementation might be non-interoperable.
• Different filesystem structure. Not only there is a difference between "" on Windows and "/" on Unix-likes, but there are "special files" that might or might not be present like "/dev/null".

In theory everything listed here can be resolved: custom loaders can be written to support different executable formats, different conventions and interfaces do not cause problems if the whole program uses the same set of them. This is why projects like Wine can run Windows binaries on Linux. The problem is that Wine has to emulate functionality of Windows NT kernel on top of what other OSes provide, making implementation less efficient. Such program also have problems interacting with native programs as different non-interoperable interfaces are used.

Source-compatibility layers like Cygwin can be inefficient, too, when emulating POSIX system calls like fork() on top of the Windows model. But in general Cygwin has an easier job than WINE: programs need to be recompiled under Cygwin. It doesn't try to run native Linux binaries under Windows.

In addition to everything else even with identical instructions even the calling conventions can differ, that is the placement of parameters on the stack or in registers, the order parameters are found, what registers must be preserved across a function call, how return values are passed from callee to caller.