There's your problem right there. Don't minimize windows in OS X just because that's what you are used to from decades of training on Windows. Hide the window instead (CMD+h). This way when you get back to it with CMD+Tab it magically appears again.
On the original topic. The whole idea makes me laugh. There is no way anyone driving with a mouse is going to be faster than I am with a keyboard. Navigating the filesystem, manipulating the filesystem, editing text esp. is laughable (I love VIM and nothing can come close to the speed I can edit in VIM, esp. not anything you have to drive with a mouse). Very few applications are better done with a mouse/pad (like Photo editing in Photoshop, but even there various keyboard shortcuts are faster than navigating submenus).
Your advice on hiding and switching applies to applications rather than windows. Consider this: you have four terminal windows open. You want to get toggle between two of them. Mac only has rotate (CMD+`), not toggle. There's no equivalent of the alt+tab combination in win32+gnome.
> I love VIM and nothing can come close to the speed I can edit in VIM, esp. not anything you have to drive with a mouse
A contrived example, but I'd like to see someone edit a Java project faster in VIM than I do in Eclipse.
Look, I know how to use VIM better than the next guy (you'll just have to trust me on this), but when it comes to writing code for large projects I can't stand using VIM. It makes me feel like I'm looking through this tiny window to my code. Give me a mouse and a powerful IDE, and it's like I suddenly have a 10,000ft view of the world.
I prefer Eclipse with VI plugin. You get the best of both worlds. And if I'm not happy with the vi plugin implementation, I can always continue editing in actual VIM by typing :vi in Eclipse.
All, that being said, I have heavily customized VIM with ctags, cscope, Command+T plugin and taglist.
Command+T alone is really worth it, you can open any file in the entire project structure by just typing a few letters (just like Eclipse's CTRL+SHIFT+t, but works on any file type).
With all these I can navigate code, and edit pretty much like I am in Eclipse, but unlike Eclipse this combo works for C,C++, Ruby, Python, Perl, Javascript etc. as well.
In that case, I think it would depend on the task at hand. For refactoring code and moving massive swaths of text around, stock Eclipse would win. For making small patches and writing new code from scratch, VIM would probably win.
I am referring to software such as viplugin. You're still in eclipse, so anything you do in eclipse without the plugin still works, but you also get Vi-style editing.
The point here is that the discussion is about input styles, not "IDE vs Classical Editor".
Not sure what is the practical and/or logical purpose of differentiating "hiding" applications and "minimizing" windows. They do one and the same, with the exception that "hiding" hides the entire app (with exception of Photoshop), and minimizing moves a window to the dock. IMO, two different behaviors for essentially the same thing - I can't think of a strong enough use case where you would want to hide instead of minimize (or minimize vs hide).
Back on topic, here's another thought (which I alluded to in my original post, but could not articulate well): could it be that their study included shortcuts that were too complicated? Could their results be skewed because in some instances it was easier to grab the mouse than to perform finger-gymnastics or to even remember the complex key combinations? I think the results of their study were glaringly obvious: the answer isn't "Move everything to the mouse" but "Improve keyboard shortcuts"
On the original topic. The whole idea makes me laugh. There is no way anyone driving with a mouse is going to be faster than I am with a keyboard. Navigating the filesystem, manipulating the filesystem, editing text esp. is laughable (I love VIM and nothing can come close to the speed I can edit in VIM, esp. not anything you have to drive with a mouse). Very few applications are better done with a mouse/pad (like Photo editing in Photoshop, but even there various keyboard shortcuts are faster than navigating submenus).