One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.
Let me sketch you something of a theoretical proof here, then.
1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster.
2) The absolute upper bound on the simplest possible way of aiming at a single pixel of 4K UHD screen with just two keys is 23 key presses. 14 key presses if you're aiming at 16x16 squares (mouse rarely needs to aim better). 12 keypresses for arbitrary pixels with four keys (home row). 8 for 16x16 square with four keys. 5 presses with full set of English letters, for arbitrary pixels. That's an upper limit. It's slower than a mouse, but only by a little bit (within the same order of magnitude).
3) Generalizing this, the upper bound of keypresses you need to touch arbitrary element on the screen is given by log_n(number of elements), where n=how many keys you want to use. +1, if you need some sort of activation key before (to switch between typing and selecting). This quickly drops to 1-3 keys, and you can get even better if there's some structure to the expected workflow (see e.g. tab stops in any sane form in any UI that isn't suffering from acute JavaScriptitis yet).
4) 1-3 random keys are faster to press than clicking a random object on a screen. That you can time for yourself trivially.
Basically, unless you're dragging arbitrary pixels around, for almost[0] any task one could easily design a keyboard-driven UI that's faster. Those kinds of UIs are not omnipresent (with the exception of Windows-style "accelerators" and tab stops, which the web is doing its best to get rid of), but they show up. In fact, properly configured Vim and Emacs are full of these kinds of UIs for programming tasks (see e.g. [1]). Which is exactly why you keep seeing people telling you Vim/Emacs are more efficient to work in.
--
[0] - I'll make concession to visual arts here, but take a good look at Blender to see how far you can go with keyboard-driven efficiency improvements for 3D modeling.
For your point in 1) that won't apply on any kind of navigation. I have to ls -l / dir multiple times to view whats in my folder and go back up with various key presses, versus just hitting the breadcrumb in windows explorer.
Not sure I fully understand 2-4 but the fundamentals still remain, i want to do a git pull i alt tab to my command line, already two presses, then i find my src directory, and pull. Or just right click on my IDE and click pull?
> i want to do a git pull i alt tab to my command line, already two presses, then i find my src directory, and pull. Or just right click on my IDE and click pull?
Or you're using Magit, in case of which it's "C-x g" to switch to magit from any buffer associated with project (a file, compilation output, whatever), and then "F p" to issue a pull from origin. Which is 4 key presses (6, counting CTRL and Shift), and likely in your muscle memory. Every other git command is accessible similarly.
Point being, for any mouse interface like this, you could - and in vim/Emacs, often do - have a similar, but more ergonomic keyboard interface. Points 2-4) were about showing that this applies to almost all software in general, not just to editing code.
Blender is an amazing example. I was daunted by the thought of learning the rich set of hotkeys until I saw it compared to vim. Learning vim or emacs is well worth the effort, inspiring confidence that blender is as well.
