The company I was working at used the OpenWatcom compiler that lets you tune structure padding with a compiler flag. Also, they "serialized" their data by simply writing arrays of structs to files and reading them back in later. Raw binary files, no conversion whatsoever.
So one day - I hadn't been there very long - I was given the task to make a certain change to the application, as well as a copy of a "database" to experiment on. I made a first adjustment, compiled my code, ran it and - BAM! It took me nearly a day to figure out that I had "forgotten" to pass a certain variable to make which in turn resulted in a certain parameter being passed to the Watcom compiler that caused it to use no structure padding at all.
Without that variable/parameter, I had compiled the program to use a different padding (i.e. use padding at all), so when my program read the data file (having been dumped by a version of the program being compiled without padding), it barfed, so to speak.
That problem caused me to do a little reading on the matter. I sure wish somebody had pointed that article out to me back then. (Assuming it had existed back then, with "back then" being about October 2007.)
There's definitely some cases where you shouldn't follow the "biggest to smallest" ordering, but they're usually pretty obvious when you run into them. They usually involve inheritance and such.
char *p; /* 8 bytes */
long x; /* 8 bytes */
char c; /* 1 byte */
char *p; /* 8 bytes */
long x; /* 8 bytes */
char c; /* 1 byte */
char pad[7]; /* 7 bytes */