1. If you have your own bootloader and you make it check the CRC then shouldn't the compiling or boot loading process calculate that during upload and store it in its own data area? It shouldn't appear as a constant in your C++ code.
The correct CRC must be calculated when the binary file is built. After that, there is opportunity for corruption. If the bootloading software wants to check the CRC it's fine, but it needs to know the correct CRC to compare to. An awful simple place to store the correct CRC, is at a fixed address near the end of memory.
The bootloader FW as well, has to know the correct CRC after the code is loaded. Every time the micro powers up, it will verify the application firmware is not corrupt before running it. If you write safety critical code in regulated industries (FDA, FAA, etc), you are required to do this.
2. Yes, but how do you get that number out of the programmed chip? Downloading the raw binary is something only the original programmer can do and that programmer probably has other ways to see which version is on the chip. Like a sticker on the PCB?
As long as the protection fuses aren't set, anyone can read the image out with avrdude. Even if it's some backward sketch that does nothing but enter an infinite loop, they can still read the image out with avrdude.
Stickers on PCBs started to go away in the 90s when flash memory became cheap. The firmware would usually be updated and nobody would open the product just to change the sticker. Even if a chip does have a sticker on it, in 2016 you pretty much always read it out of the device just to be sure.
3. Data which changes should be in the data area, not the CRC protected program. Page alignment can be indicated to the compiler in other ways.
As an example, a product uses a 4kB map of calibration data. The cal data must be nonvolatile so it's not in the data section, 4kB is too big for the eeprom, but since cal data is only written once or twice it's common to put it in the flash (similar to the previous poster's Serial Number example). The cal data would need to be preserved each time the executable is updated, which is most easily done by placing it at a fixed address.
4. What would the bootloader-with-CRC do with this information?
The idea about the LED is if this information is used by people other than the original programmer who has all the source and the binaries, there must be a way to get it out of the chip without owning an ICSP programmer.
Well certainly there would be ways for the firmware to identify itself beyond reading out its binary image. Locating the ID info in a place that allows the developer or a software tool to identify an image without executing it, doesn't prevent the firmware from having a way to read the info out through a comm interface.