I work in bioinformatics, where the underlying technology changes often enough that you don't have to think too much about portability. If a new fundamentally different system emerges, my old code will probably be obsolete before I have to think about supporting it on the new system. I was around during the 32-bit/64-bit transition (which was painful), and I've been porting code targeting x86 to ARM (which is usually not). Here are some thoughts I've had about portability and system features:
Your code includes your build system and dependency management. If they are not portable, your code is not portable.
I'm a language descriptivist. A standard is an imperfect attempt at describing a language. When the compiler and the standard disagree, the compiler is right, because it decides what the code will actually do.
OpenMP is an essential part of C/C++. Compilers that don't support it can't compile code that claims to be C/C++.
There is no point in pretending that you support systems you don't regularly use. In my case, portability means supporting Linux and macOS, x86 and ARM, GCC and Clang, but not in all combinations.
Portability, simplicity, and performance form a triangle. You can choose two and lose the third, or you can make compromises between them.
Pointers are 64-bit. If they are not, you need a lot of workarounds for handling real data, because size_t is too small.
Computers are little-endian, because that enables all kinds of convenience features such as using data from memory-mapped files directly.
Compilers should warn you if you use integer types of platform-dependent width, unless the width is required to be the same as pointer width. And except as argc and related variables.