The issue with open redirects isn’t that you can modify anything on the user’s end, or a website’s backend but rather use the redirect for phishing attacks.
But the “aha” moment you’re probably looking for is the attack vector.
The attacker would have to convince a naive victim to click on a crafted link.
For example, say I had posted a link on a forum that looked like microsoft.com/go/?next=http://axsharma.com. You may be under the impression that you were visiting a Microsoft-owned page, but you’d get redirected to my website because Microsoft’s backend didn’t prevent “external” redirects.
Of course, whether this is a vulnerability or not is largely context-dependent. In the case of StartupTree, the “open redirect” was in the login workflow which is problematic.
However, there are legitimate use cases of “open redirect” too — prone to abuse.
For example, Google Search uses open redirects before redirecting you to one of the search results. This lets them both analyze a link (for potentially malicious reputation) and gather analytics. The URL below still works. You’d think you’re visiting Google but would eventually get redirected to example.org via their backend. They don’t consider this a vulnerability, of course.
https://www.google.com/url?sa=t&url=http://example.org/&usg=AOvVaw1YigBkNF7L7D2x2Fl532mA
Lastly, open redirects have been abused to generate SEO for malicious sites by using the reputation of existing web sites such as weather.gov:
Hope this helps.