I know there will be a really good explanation...

But why in Allegro 4 with bitmaps I can just get the height/width of a bitmap
but ->w, or ->h, etc, but in Allegro 5 I have to call the al_get_bitmap_width/height function?

It seems a backward step in the pursuit of elegance imho, but as I said I am sure there is a really good explanation why I have to keep typing out so many characters. Which incidentally increases the line length, and is a slight irk when
formatting the text for readability. I know I could define it away, but I was wondering why it had ended up like it had.

It's generally accepted that you should use getter and setter functions for field access in an API and never allow directly reading or writing them.

Ahh those general them.... shakes his fist at them and mutters something about buffer overruns in his day were do with trains not coding

Making types opaque (only interactable through pointers to them) simplifies the backwards compatibility story. Since 5.0, the internals of ALLEGRO_BITMAP changed significantly, and that would not have been possible if all the variables in that struct were directly accessible. I suppose that doesn't really apply to width/height, since those remained basically the same... but consider al_get_bitmap_flags. By your argument, you'd prefer bitmap->flags, and that was what al_get_bitmap_flags returned... but recently, it got changed to this:

int al_get_bitmap_flags(ALLEGRO_BITMAP *bitmap)
{
   if (bitmap->parent)
      return bitmap->parent->_flags;
   else
      return bitmap->_flags;
}

I.e. sub-bitmaps now inherit flags from the parent. Something like this would not have been possible to do in a backwards compatible way if we let you access that member directly.