Perhaps I should have used the word improper, instead of incorrect. So, it's correct the way it is, because it is as the designer intended or perhaps it is just the way it is and happens to work by accident.
One of the benefits of Optiboot is it fits in 1/4 of the size of the old bootloader, leaving an additional 1.5K of user programming space. So, the new design does not properly set the beginning of the bootloader section to the first instruction of Optiboot and wastes user programming space.
OK, now what happens when the bootloader is burned? The chip is erased, which results in a flash memory full of FFFF, then the bootloader is programmed in the upper portion of memory. Then, the fuses are set so execution starts in the middle of a bunch of FFFF invalid instructions. As of the current version of the ATmega328P chip, FFFF just happens to do nothing (or very little depending on who you talk to). So far, so lucky. It seems to me it is just improper and warrants correction. Perhaps I'm just in a mood.
Slightly related to this, in the IDE, the upload sketch using a programmer should unprogram the boot reset vector (BOOTRST) fuse, so execution of the user program does not begin with a bunch of FFFF invalid instructions in the bootloader area and then wrap around to the low address range, or worse yet execution begins somewhat near the end of a long user program.