You have a bit of a misunderstanding there. The paragraph you quoted doesn't actually say anything about framebuffer objects yet. It just talks about a single texture. While we usually understand a texture as a single image, it is (or can be) actually comprised of a set of images. This might be because it is an Array Texture or, even more common, it just has a set of Mip Map Levels (basically increasingly smaller filtered versions of the base image, used for advanced texture filtering). And yes, within a single texture, all those images have the same format. However one such texture usually makes for one render target.
All this has nothing to do with multiple render targets yet. And you will notice that the later parts of that article that speak about the actual framebuffer attachments, specifically the part about Framebuffer Completeness don't say anything of the sort of all attachments needing to have the same format, because there is no such restriction. They don't even need to have the same dimensions. The only thing that is required is that they all have the same number of samples (if they're multisampled at all).
It is possible that an implementation still doesn't support all kinds of image formats and combinations, but there are some that are required and a "reasonable" implementation will support a wide variety of format combinations, including ones with mixed pixel bit-depths.
There was a stricter limitation on the images in the original GL_EXT_framebuffer_object extension, namely that all attachments have the same size and internal format. However, since it has found its way into OpenGL 3.0+ core (and was from there exported back as the more advanced GL_ARB_framebuffer_object extension) they loosened these restrictions.