Originally I had all images using 32-bit alignment, but that caused fonts to use a lot more memory and disk space than they would if we dropped that constraint. I did some testing and found that the speed difference wasn't really noticeable (roughly a 2x penalty for unaligned access, as I recall--you'd only be able to tell if you were in a really tight loop) so I switched to 8-bit alignment. Except, for some reason, in pd->graphics->newBitmap()? 
I can't remember now and the commit logs aren't helping. My best guess is I wanted you to be able to take the fastest route, a single memcpy(), when you're drawing a full-frame image to the screen. ..But most of the time those would be loaded from disk. 
Slack is no help either, but I did find our conversation about the change, and I mentioned that 8-bit alignment was actually faster for fonts, presumably because it fits in the cache better.
So: Images created with pd->graphics->newBitmap() happen to have 32-bit aligned data through oversight/accident of history, but as far as I can tell that's the only place we added that constraint.