As a software developer, I deal with forks all the time. A fork not only refers to forked blockchains, but also to the fork of a software product.
Software forks can be a good thing or a bad thing. When a fork offers new features, or caters to a new audience, that's awesome. Like Kubuntu being a fork of Ubuntu, MATE a fork of GNOME, LibreOffice a fork of OpenOffice... But forks that do not offer innovations, just compete over the other fork's user base - are terrible for everyone involved.
As an example, in 2011, the FFmpeg project, a popular open source library used for decoding audio/video, was forked into FFmpeg and LibAv. There was no real reason for the LibAv fork aside from discontent over the attitude/social behaviour of the FFmpeg developer(s).
The fork turned out to be a huge pain for everyone involved. FFmpeg/LibAv developers spent a lot of time porting changes from one fork to another. The fork's prime "innovation" of "improved API's" turned out to be its biggest downside because of the compatibility issues caused. Some application developers had to support both FFmpeg and LibAv (which differed in various frustrating ways) in their applications because they didn't know what the user had installed. When a developer would find a code snippet on the internet, he had to check if it was meant for FFmpeg or LibAv, and then adapt it to whatever fork he was using. End users had to manage separate installations of FFmpeg and LibAv depending on what their applications wanted. Security researchers frequently found vulnerabilities in one fork that had already been fixed in the other fork. Linux distributions had a problem dealing with FFmpeg/LibAv packages because in most cases they would conflict one another - you could not have both installed at the same time.
We can safely say that thousands of man-hours were wasted just because of the childishness of a select few deciding to start this useless fork. Even though LibAv offered next to no innovations over FFmpeg, the fork stayed around for years, simply because there was still a vocal minority developing and promoting it.
Here's a good article on the FFmpeg fork:
https://lwn.net/Articles/650816/
What are the lessons learnt here? Drama caused by human emotions - be it jealousy, superiority complex, "not invented here" syndrome - are reasons that can keep forks going for a long time, even when in the minority.
In the case of Ethereum, it looks like the drama that this hard fork would cause has been underestimated greatly. The Ethereum foundation went ahead with the fork full knowing that a nontrivial portion of the users had voted against it.
Let's hope that the winning Ethereum chain is now decided quickly. I would hate to see too much time wasted on maintaining two different versions of an entire eco-system.
Let this be a lesson to the crypto community that forks are a desperate measure that should never ever be used without a very clear consensus.