"Theoreticians" - this is a pretty bold assumption. The members of the OpenGL architecture review board consists of people who design graphics hardware, write graphics drivers, author graphics engines, and use the OpenGL API in applications.
Yes, we want our code to work on MacOSX and Intel hardware but what the theoreticians completely overlook is...
In that case, you've got a pretty clear set of restrictions which would preclude you from doing much GL3 or GL4 specific work anyway, even with compatibility mode. While I'm sure they have their reasons, it seems a bit short-sighted to me. Dealing with third-party API changes is a normal part of software development, which software managers need to account for (usually as "software maintainance"). Legacy to Core just happens to be a larger change than most, and one which isn't even being forced upon you.
....management also has a say in the matter, resulting in the following:
- no rewrite from the ground up
- no change of general program flow
- no time consuming changes
However, under those development restrictions I don't see any problem with setting out the hardware and platform requirements in your application's system requirements (Windows - Nvidia or AMD).
Except that they didn't. Compatibility mode remains for those cases, for GL implementors that are willing to support it. Even Apple has a GL2.1 compatibiltiy profile - you just can't use GL4 features with it, which sounds like your application couldn't use anyway.
You cannot pull away the rug under some existing software in the vain hope that everyone can afford to take the time to reorganize all the data.
Sounds like your app suffers from the "small batch problem" which a lot of people in the industry are attempting to resolve (AMD with Mantle, Microsoft with DirectX 12, Nvidia with their 337 series GL driver). Nvidia does well in immediate mode because it has an excellent emulation layer which is batching up all the vertices for you into buffers. They also optimize their display lists during compilation. However, you mileage with vary, as some immediate mode and display list implementations are quite a bit slower.
See above: The inability to just put some data into a buffer without some insane driver overhead. Yes, just an efficient method to replace immediate mode draw calls. You may ignore this problem as much as you like, that doesn't change anything about the cold hard fact that our 'big app''s life depends on it.
Current hardware simply doesn't like small draw batches with rendering changes (GL state changes) between them, so it's up to the software to optimize the draws and buffer submissions. You can either do it yourself or hope the driver does a good job. The draw batcher we wrote provides very similar performance in Core GL mode to our previous immediate mode code. Perhaps a bit of profiling is required? Especially if, as you say, your big app's life depends upon it.