when I build the hex file, jumpMain winds up completely un-referenced.
putting code in the .init sections implies a specific physical ordering of the code, so it's POSSIBLE that code that isn't referenced is executed anyway, just because it physically follows other startup code that doesn't have a terminating jump or return. But it looks like stk500boot is currently broken, because the user-provided code in init9 is placed AFTER the init9 code from the startup files, which already contains the call to main(). Thus jump_main is never reached. Optiboot uses .init9 to position code as well, but it completely suppresses ANY of the normal startup code.
is jumpMain just something in the code that never got cleaned up?
It looks that way.
I'm not sure what stk500boot is trying to do - while the comment says the code isn't linked with crt1, the commands to actually do that seem to have been removed from the Makefile a long time ago (along with the attempt to "reduce code size.") The code in jump_main duplicates functionality that the other startup code does anyway; I think it's essentially 'dead code' that should have been removed a long time ago.
my hex file is a bit smaller 18k vs 21k than the "good hex file" but then I've built this with the toolchain included in Atmel Studio 6.2. Is THAT anything to be concerned about?
I don't know. I get three different object file sizes with three different versions of the compiler, and none of them matches the .hex file packaged with the arduino IDE. 
With Optiboot, changing compiler versions is frequently "exciting", but optiboot is much more dependent on internal details of the compiler operation, and the problems are usually obvious (doesn't compile at all, doesn't fit in the required size, etc.) stk500boot is more conservative in what it does, and has more relaxed "requirements", so it should be less sensitive...