For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects".
This can be powerful, but it is also very disorienting. Which means it can be hard to learn to do even basic things in powershell, things that would take only a pipe or two and a couple unxutls programs in cmd.exe.
In cmd.exe, easy things are easy and hard things can be really hard. In powershell, hard things are hard (as opposed to "really hard") and easy things are hard.
The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell...
Apart from that it's bearable!
You even get autocompletion across commands: if you type "ls | sort _" where _ is the cursor, then you get a list of properties that you can sort objects returned by ls by (LastAccessTime, LastWriteTime, Extension, etc).
Only if both commands support objects. If one of them doesn't then PowerShell just deals with text. I've sent the output of PowerShell commands to perl scripts and GNU utils without any problems. It just worked. I'm still a powershell newbie, and this has made it easy for me to learn it while still using what I know.
https://github.com/bmatzelle/gow/wiki/executables_list
https://github.com/bmatzelle/gow/wiki
Kept up to date, every .exe (once installed) is self-contained (no external .DLLs) and portable to just about any Windows box I've run into.
No Cygwin or MinGW installation required.
Bash is actually available in the list (albeit an older version) if you really wanted "bash on Windows"
The initial github commit has comment "Initial import of the code I developed back in 2006. Nothing has been changed since then.", and nothing has been changed since that commit (with exception of docs, Gow.nsi and gow.vbs files).
They are complementary.
I currently have to use Windows at the customer I'm working for. I've installed Console which gives tabs and better copy-n-paste on Windows. See http://sourceforge.net/projects/console/
I'm not sure if clink and Console will work together, but I'll have to try it.
I'm giving ConEmu a try and it looks awesome!
http://code.google.com/p/conemu-maximus5/
Scott Hanselman wrote a blog post about it:
http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...
If it's there you have it already.
It is definitely worth it for some people, but time is a limited resource, and others will benefit from this kind of project.
Also, AFAIK there is no 64bit version yet, which for me is a dealbreaker (I often work with files larger than 2GB).
Cygwin commands that run slower than Windows counterparts are typically those that are syscall heavy, where those syscalls are significantly different on Windows and need lots of work for emulation. The biggie is fork(); it's better by far to write scripts etc. in such a way that they stream results rather than iterate and create new processes.
So, for example, rather than write a script that converts Unix paths to Windows paths with iterated calls to cygpath -w, instead pipe the paths to cygpath -w -f -. Rather than use pipe-to-sed (like "$(echo $foo | sed 's|bar|baz|')") for ad-hoc edits, try to use shell substitutions instead (like "${foo/bar/baz}").
Another thing that can be slower in Cygwin is find, when run over very large directory trees. I wrote a wrapper script (I call it rdir) that runs "cmd.exe /c dir /b" and massages the output into a Cygwin-style format. I also have the same script written in terms of find, so that my scripts that use it work on Windows, Solaris, Linux and OS X.
But I have to say, the biggest limiting factor in me solving ad-hoc problems is composing the tools available, rather than the actual runtime speed of the tools themselves. Having all the Unix tools available makes my life far easier in this respect. They could be even slower, and I wouldn't mind, because I would still be saving lots of time compared to what Windows provides; and my scripts usually also work on all my other systems running different OSes.
PowerShell doesn't even support simple fork-join like bash does trivially:
for x in {1..10}; do (sleep $x; echo $x) & done; wait
I use this idiom a lot when dealing with lots of multi-gigabyte files. PowerShell is mostly useful to me when I need to access Windows-specific stuff that Cygwin doesn't do well, like WMI.Think of Far Manager as Midnight Commander, more or less.