Interesting, so it sounds like the slowness seen in 3 and 5 are due to the much larger bitmap size. You would have 183.55 times more bitmap data to deal with even when keeping everything else equal. Perhaps it would be interesting to have a mode that uses 16x16 bitmap but have 3671000 triangles or 1835500 calls (ie. scaled by that 183.55 factor) to compare against.
Do 3 and 5 actually reflect realistic situations that may be encountered in real lix levels, or is it more like a stress test for benchmarking only?
I don't pretend to be anywhere close to an expert on this stuff, but regarding 1-3 vs 6, I think I've heard/read that you basically want to batch GPU calls as much as possible. That way the driver can work out the most efficient way to schedule the given work across the GPU's pipeline taking as much advantage of parallelism as it can. So I would expect (but haven't look at the actual data to confirm) 6 to be less efficient than 1.
Regarding OpenGL, my main worry would be that I think for Windows, even though most graphics drivers support it I don't think it's really required, at least not to the degree that DirectX support is. DirectX is first-class citizen in Windows world compare to OpenGL. You can bet that nothing Microsoft writes for Windows would be using OpenGL, and many games written for Windows also will likely use DirectX because it's where Microsoft and graphics card vendors will spend most of their efforts in terms of enhancements, improvements, etc., such that when performance is paramount it will make more sense for them to target DirectX. As a result given this business climate, if nothing else I'd expect that for the same Windows graphics driver, the DirectX aspects will likely be much more well tested and maintained, compare with the OpenGL aspects. The situation is such that for example,
Chrome apparently uses a OpenGL->DirectX translation layer in Windows to handle WebGL content, rather than directly targeting OpenGL.
So if Allegro 5 can intelligently choose between OpenGL vs DirectX for its Windows implementation, that may be advantageous compare with always sticking to OpenGL. Linux is of course different since it's just OpenGL in that world.
Triangles vs quads may not be that good a reason to jump to OpenGL anyway, in terms of performance. At least the given data on this test computer would indicate the texture size can be much more of a bottleneck. It would not surprise me that at least for some lower-end drivers, their quad support may well be handled by the driver internally by turning the quads back into triangles especially by the time things get to the GPU.