Serialization is one, but anything involving casting from one struct to another (e.g., if the Berkeley sockets implementation changed the size of struct in_addr), anything requiring careful management of memory alignment (e.g., SSE), etc. could potentially be broken. Never mind the inevitable reckless coding practices that arise in the wild all the time (someone decides to #define a magic number for allocation purposes instead of using sizeof...).

On the other hand, a large number of constants are supposed to be tweakable, to the extent that many are designed to be set at compile time.

Anyway. OP article had good points overall, I'm just not sold on some of the specifics.