The answer is there is no technical NEED for more than one way to program the part with respect to getting firmware in the device.
The technical need to get firmware in the device is simply have a way to update firmware inside the target processor.
As long as you have a way to do that there is no technical need for another.
Note that I said "technical need to get firmware in the device" there can be other wants or even needs that trump this such as ease of use, minimizing h/w devices, or manufacturing requirements.
In the very early days of Arduino or even pre-Arduino, there was no bootloader.
The chips were programmed using the ISP capability built into the AVR chip.
That said, the h/w interface used for in circuit programming is often a manufacturing requirement for the chip maker as they can use it to test the chip on the assembly line to verify that it is fully functional.
This same circuitry also allows factory programming of parts, which is very useful
for manufacturers using the part in their designs directly on their assembly line.
Also, this same in circuit circuitry often has support for s/w debugging.
In chips that have a Harvard Architecture where the firmware lives and runs in flash, there is no way to do breakpoints for s/w debugging without some kind of h/w assist.
So for all these reasons, a h/w interface for testing, firmware loading, and s/w debugging tends to be a requirement.
A serial based software bootloader can be a nice to have or even a requirement for other reasons.
Having been involved with manufacturing products in the past (millions of units), that included custom silicon that used custom ARM based chips, granted that was 25 years ago, but still I'm not seeing the value or need for a putting h/w support inside a chip for a bootloader that uses some kind of serial protocol.
I'd just stick with lower level h/w interfaces.
i.e. keep things simple and minimize any potential issues to avoid cost and time overruns.
As far as bootloaders go on the older AVR based devices,
IMO,
At this point there is no longer a need for a bootloader on older AVR based devices such as the UNO and the MEGA boards.
The AVR could always be programmed using ICSP.
An no, this would not require the user have any additional h/w nor would it changing the current user experience of being able to use a USB interface and do everything from the IDE GUI.
For quite some time the onboard FTDI USB to serial chip was replaced with an AVR 16MEGA16U2 chip.
The s/w in this chip could be tweaked to provide not only a virtual serial port but also emulate an ISP programmer such as USBASP or USB Tiny.
There would also need to be a small tweak to the board layout to add the appropriate connections between the 16MEGA16U2 to the ATMEGA part to allow the 16MEGA16U2 to use ISP programming to program the main AVR chip.
This could eliminate the need for a bootloader and its associated resources in the main AVR chip.
It would also allow working with blank chips in the case of replacing a burned up chip all without the user needed to ever use an actual ISP programmer.
It would still allow using the serial port and even a bootloader, but a boot loader would no longer be needed as the 16MEGA16U2 could ISP program the main AVR.
I have contemplated taking on the 16MEGA16U2 s/w part of the project for quite a few years but never got around to it.
--- bill
