The "buffer" model. Half the speed of using vim in a project for me is the ability to manipulate the layout and having different "windows" on the same file. One of my most common workflow is to split the current window and navigate to a different part of the same file for reference purpose (can quickly switch to another file with fuzzy finding too).
And quick integration with external tooling. Creating an extension for vscode is cumbersome.
This works the same in vscode as it does in vim as far as I am aware. e.g. `:vs` to split the window and moving between windows uses the same shortcuts as it does in vim.
The fundamental difference is that in Vim, a tab/window contains splits, whereas in VSCode and every other editor AFAIK, a tab is a child of a split.
In Vim I can have test and implementation side-by-side in tab0, and then two splits of the one file in tab1, a header file, impl and test in tab2, etc.
With another editor, I have to switch tabs in split 1, then switch tabs in split 2, rearranging or adding more splits as needed when moving between different groups of files.
And quick integration with external tooling. Creating an extension for vscode is cumbersome.