They're built to open 100KB source files and be easy for developers to maintain. Which, granted, covers 98% of use. There was a time when handling files that size required optimizations that might detract from maintainability, but hardware is fast enough now that for files measurable in KB, it makes more sense to optimize the code for the developer rather than for performance.
Version 3 of my favorite text editor could open a 400MB log file in 2-3 seconds on a circa-2002 computer and search or scroll through it like silk. Version 4 beach-balls for 5 minutes for a 40MB file on circa-2012 hardware.
That said, I might ask why you're trying to open a 2GB text file in an editor. Most files that size are either media or computer-generated text like log files.
With the latter what you're generally trying to do is read and filter them, not write. The most sensible way to do that might be to use grep to filter the lines you need into a new, smaller file. If you do this frequently, consider an ELK stack (elasticsearch, logstash, kibana) for ease of use.
If you just need to read the one file and you're not yet sure what you want out of it, I recommend less (the command line tool) to scroll and search. It may take a minute or two to open, but should be performant after that.
If supporting feature x that nearly no-one wants makes popular features a, b, c much harder to implement then it generally makes engineering sense to forgo x.