I can't give hard numbers for performance improvements, partly because it will vary wildly by what machine you have. I have however seen comments that "it should be faster than this", and this would be a definite step in that direction. The initial step of excising the Begin/End paradigm - made obsolete by GL 1.1 for crying out loud - will not have any compatibility effects - this is pure win.
Of course, the patches I've already done and posted will have zero measurable performance impact. They apply to a part of the code that is not performance limited at all. There are other, more important reasons for dealing with it though.
Looking at my profile with retail data, I see that roughly all of the functions that use glBegin/glEnd are called at least once per frame and usually a lot more than that. This corresponds to many many unnecessary GL API calls per frame. Each GL API call is in itself an overhead that it is wise to avoid.
The "new features" that we should expect are compatibility with newer and more interesting platforms. For example, MacOS X will not add support for new GL features to the "compatibility profile" implementation it supports. New features will therefore appear only in the "core profile" implementation. Therefore in order for the Mac port to keep up with other platforms in terms of rendering features, the whole engine has to be made compatible with Core Profile, which happily is also a long way towards GLES2 compatibility.
And, of course, OpenGL ES2 support opens up non-x86-based Linux platforms, particularly the Raspberry Pi that I'm planning to target once the cleanup operation is done. ARM based platforms generally don't come with PC-type graphics cards, and therefore don't see any need to support "legacy" OpenGL since it doesn't provide any features that mobile games and navigation apps can't easily do without. An, if they *do* eventually move on, it will likely be to GL3 Core Profile, not back to legacy GL.
The later stages of the conversion have the *potential* to cause compatibility problems with older GL versions, specifically pre-2.0. I think that this can be dealt with by the new state manager I proposed - by knowing what sort of rendering is to be done, it can adapt to shader mode (using Core Profile compatible calls exclusively) or fixed-function mode (using legacy calls exclusively). The rest of the rendering code would then be decoupled from that decision to the extent possible - obviously some effects are not available without shaders.