In my experience, passing colors as RGB888 is extremely uncommon, because I thought it was impossible! 
n.b. NVidia drivers are famous for accepting invalid GL program behavior and doing a fairly good job of tolerating it. I wouldn't be surprised whatsoever if their driver was silently allocating the extra 33% space required and inserting the padding bytes for you!
I haven't double-checked with the actual GL spec documents, but I would've guessed that a 3-byte attribute stride is illegal. Using the D3D API there's actually no way to request a 3 byte color attribute.
If I remember correctly, AMD hardware requires buffer loads to be at least 2-byte aligned, so a 3-byte attribute wouldn't be supported in hardware -- supporting it would require quite complex vertex-shader code that does two 4-byte loads and then swizzles / shifts the bytes out of them... so technically possible, but at a high computational cost.
You could actually implement this yourself -- make a buffer of 32-bit integers, but put your existing data into it e.g. 4 colours in three elements [RGBR][GBRG][BRGB]. Then bind it to your vertex shader as a "buffer texture" (or read-only SSBO), then gl_VertexId to fetch and unpack the data yourself.
Alternatively, are there any other vertex attributes that you could fit into this extra "padding" byte?
Or, would you be better off using 16-bit colors instead of 24-bit? I've had good results using YCoCg color-space, with 6-5-5 bits per channel, manually packed into an integer with bitshifting code 
