by context switching to the grey matter to inquire what the name of the file is and then tab complete your way to said file vs. where you visually "know" the file to be in standard panels (splits) with tabs (buffers) based editors.

> move a file between different windows

please don't lie to the uninformed -- one can only rotate windows within the same row or column, not across columns and rows -- it's rather limited.

> create and destroy splits, etc. is just so nice

I'd take drag and drop splits any day over Vim's adhoc implementation. If you create a split it's best to destroy it as it will never behave predictably; i.e. your split layout may completely collapse when closing a buffer.

and then cloned splits, man do I love to see the exact same file displayed across splits, nothing says maximize screen real estate usage like cloned content. Sure, can close the cloned split, but why waste one's time on an event that isn't even possible in GUI editors? (i.e. attempting to open an already open file brings you to its location, not pointlessly duplicates it).

> Every other editor seems clunky and inefficient

Feel the same way about Vim's window management, try Sublime, heck even try Eclipse, you get multiple visible tabs (buffers) per panel (split), and as an added bonus, the labels are set above the code (where top-down, left-right humans expect it), not below. You can also quickly hotkey rotate through all opened files, bing, bing, bang vs. either reading through a buffer list that has nothing to do with its location in visual space, or praying that ctrl-O doesn't start opening files from a previous session, or just saying ctrl-6 (toggling between 2 measly files) is the answer.

I think the deal with Vim is that you have to keep a lot in mind, literally, as in the entire set of file names you're working with, vs. visual editors where code location is representation (i.e. its "name").