So what's the thing that makes cmd preferable for you?

That's a really good question and one I may take some time to think abaout and come up with a more detailed answer.

For now I'll mention 4 things:

• It's not just one single thing, but rather the accumulation of many things.
• I rarely ever write .bat/.cmd scripts -- a quick search showed up just 6 that I wrote and use regularly. If I need a script, I use Perl.

  Indeed, the vast majority of the .bat/.cmd files the search turned up on my system are those that are distributed with Perl itself that are produce using the pl2bat utility.

  These are weird -- and in my opinion, woeful -- hydrid scripts that contain complete perl programs wrapped over with a few lines of batch script that simple invoke perl to invoke the embedded Perl code.

  I see no purpose nor utility in this process and abhor them; any error messages they produce have the wrong line numbers; when you try to edit them, their having the wrong extension means your editor tries to apply the wrong syntax highlighting and you end up with a garbled mess; and if you edit the original .pl and then run the command you get the uneditted .bat version instead; if you try to abort them with ^C; you get a useless damn prompt asking Terminate batch job (Y/N)? which is just infuriating. Yuck!

• In part, my preference for the simplicity of cmd.exe is related to my preference for the simplicity of my preferred editor: textpad.

  I prefer my 'simple', non-programmable editor because it is non-programmable. It is because I do not get tempted to try and perform tasks that actually require a programming language, and then waste time either jumping through hoops trying to make an inadequate tool do what I need; or having to perform a wholesale conversion to a proper programming language, once I reach the limits of the editors built-in facility.

  In the (distant) past I used various fully programmable editors; and programmed them extensively to my taste, only to find that when I no longer had access to my customised version -- as when on a customer site with protectionist policies in force; or when I changed jobs and had to use a different system were the editor I had customised was no longer available; that I had become dependent upon the things I had programmed it to do and my productively went through the floor for several weeks whilst I became used to their absence (or worse; wasted more time re-creating them as best I could in the new environment.)

  My feeling that programmable editors were more hindrance than help came a few years later when I subcontracted a guy for a month, to finish a piece of work that my workload didn't allow me time to do, and when after two weeks I asked for a progress report he had made none. I then inspected the files in hos home directores and discovered that he had literally made no changes at all to the source files he was supplied with. Further investigation -- of the nightly incremental backups -- showed that he had spent the entire 2 weeks customising the programmable editor. He'd spent his time writing reams and reams of editor scripts: to put elaborate decorations around blocks of comments; to single & double walled line-character boxes using the cursor keys; to construct and edit his timesheets; to maintain his CV -- including an entry showing his new expertise with the programmable editor!; and so on. But not a single line in any of the source files he was meant to be working on had changed.

  So it is with shells. The simpler the shell, the less likely it is that I wil be tempted to try and develop serious tools (or dog forbid, applications) using them, rather than a language (like Perl) designed for the job. Many years ago when working in a mixed NT/HP-UX environment, I developed an elaborate real-time monitoring tool using a mix of csh/sed/other *nix tools. I didn't know perl back then -- indeed, it was suggested to me and I took one look at half a dozen examples of Perl and rejected it as line noise. (In my defense, it was Perl 4 and from memory, the unknown author(s) of those examples (dug up by a altavista search) was probably no experts.

  Later when I had become a convert to Perl 5, I looked back on the extreme efforts (and hours) it had taken to get that tool working and realised just how much simpler it would have been using Perl, (probably even with Perl 4), but we live and learn.

• Finally, I infinitely prefer the line editing, command line history and cut&paste facilities of a windowed cmd.exe session to anything available on *nix.

  In part that comes down to familiarity, but it goes much further. Every keyboard I've used in the past 20+ years has had arrow keys; home & end; delete & insert; pgup & pgdn; a set of programmable function keys. These keys perform the same tasks in just about every application I use -- pdf readers excepted. Switching from one application to another and muscle memory allows me to use them in essentially the same way everywhere. And that has been the case going right back to circa 1985 or so with the earliest versions of OS/2 that I helped develop. (And even before that with DOS to some degree; though much less so.)

  Having become used to that, every experience I have had with using *nix in various forms from HP-UX to BSD to half a dozen flavours of Linux just leaves me with finding them all wanting.

  Perhaps if I had started out using *nix at an earlier age it would be different. Having said that; my first truly programmable editor was a beast called TECO(VTEDIT) (the progenitor of EMACS) on PDP & VAX hardware running variously RSTS/E, RT11, and IAS; and nothing in this world would persuade me to go back to either it or its offspring.