Small changes in their objects made the streams incompatible etc. Obviously, this was a bad idea in the first place and caused lots of issues. Side note: At some point, programmers started to just serialize their objects to write them to a binary stream from which they could be restored later. So, if size, reading/writing speed or obfuscation is not an issue, there is no real reason to use binary formats. In a nutshell, it makes things less portable, less readable, less robust. Besides, using binaries makes it necessary to define byte order, byte size of types (enums) etc. But this comes at a price: simply peeking into an Elf/Dwarf file is much more difficult than looking inside a text dump of it. The only real benefit of binary formats is that files are usually smaller.
bin file is the start address) then separate process (such as a custom piece of software the end-user or calibrator can also use) to update other parts of flash. I use raw binary always when possible and try to arrange contiguous memory for the firmware (then the only parameter needed additional to the. Intel HEX works fine, and embedded MCU binaries are often quite small even if the HEX format blows the size up by some 3x. A new "programming binary" format would be required, with headers and support for non-contiguous (sparse) data coming up with new file formats is easy, but getting people to actually use them in masses typically requires there is significant benefit to using them.
ELF contains section information, but for just programming certain memory areas, this is almost too much information and the programming needs to be directed. Intel HEX format can signify memory areas to remain unchanged (no operation) from those to be written, because the address space doesn't need to be contiguous.