Is there ever a real reason to want to suddenly change cipher suites half way through a session?
It seems a solid 20-30% of serious openssl vulns are renegotiation related.
You would have to ask people who were involved in the early days of SSL to be sure but my impression was that the motivation was centered around the idea that symmetric keys should not be used to encrypt too much information. Thus extra handshakes were thought to be needed in order to "refresh" keys.
That's not inaccurate, although I feel that people wanted to rotate keys out of a sense of unease, rather than based on an analysis of how the security bounds change as the amount of data increases.
Server-gated crypto was certainly a reason, as detailed in a comment here by geofft.
These days (and I don't know if this was in mind when renegotiation was designed), renegotiation in HTTPS is almost exclusively used by servers (often IIS) to request a client-certificate after receiving an HTTP request.
There are much simpler ways to achieve these goals and they have been implemented in TLS 1.3 to replace renegotiation. I think that people were much more confident in their ability to write correct software in the 1990s.
Now that browsers are no longer prohibited by law from making 128-bit connections outside the US, this use case doesn't matter any more.
See mod_ssl/README.GlobalID from wherever you can still find mod_ssl (e.g., https://stuff.mit.edu/afs/sipb/machine/anxiety-closet/apache...) for details on the protocol.
Despite the common belief, SSL negotiation introduces significant overhead and latency.