That doesn't seem to apply to images that aren't multiples of 8 in size, does it?

the stored image is always a multiple of 8, with padding that is ignored (and heavily compressed).

But can this lossless rotation process account for padding not being in the usual place (lower right corner presumably)?

I'm not sure if this is how JPEG implements it, but in H.264, you just have metadata which specifies a crop (since H.264 also encodes in blocks). From some quick Googling, it seems like JPEG also has EXIF data for cropping, so if that's the mechanism that's used to crop off the bottom and right portions today, there's no reason it couldn't also be used to crop off the top and left portions when losslessly rotating an image's blocks.

are there any cameras that take pictures that are not a multiple of 8 in width and height?

People may crop

Indeed. Whenever I'm using an image browser/manager application that supports rotating images, I wonder if it's doing JPEG rotation properly (as you describe) or just flipping the dumb flag.

Or lossy re-encoding.

Yes, worst of all.

Only if the image width/height is a multiple of 8. See: the manpage of jpegtran, especially the -p flag.

Slight nitpicking, but you can rotate in 90° increments without loss.