Re xiaojun:
After reading your reply, I feel there are a few points that need to be clarified:
1. Under dos, there are very few things batch files can't do—almost none! At least up to now, I have never run into a dos case that definitely could not be implemented with batch files. Why do I say this? Because the greatest strength of batch files is that they can call on every resource that can be called, including all kinds of internal and external commands, all kinds of programs, tools, and software that can be found, and even source code in various languages can be directly interpreted and executed in batch files, asm, bas, c, and the like. By organically combining all these resources, the functions and interfaces that can be achieved are beyond what anyone can imagine. So you could say batch files fully embody the bold saying, “Nothing is impossible, only things you haven't thought of.”
2. Under dos, the occasions where batch files are truly used are less than one tenth; many cases that could originally be easily implemented with batch files are abandoned by users. Why is that? Because of the cost issue—in other words, the effort put in and the result obtained cannot be brought into balance. There are many kinds of cost here: compatibility, generality, robustness, ease of use, applicability, and two other quite important ones, namely the space and time required to execute a batch program. Of course there are also many kinds of gains: a program that can run normally, a program that can run perfectly, a program that can run anywhere, the sense of achievement from programming it yourself, the satisfaction of having a complex problem solved simply, and so on. But I believe very few people write batch programs longer than 10 lines; I myself also rarely write programs over a hundred lines, mainly because of “complexity.” Complexity severely damages the lightness and speed of the program, and at the same time harms the various kinds of cost I mentioned. As for whether these costs can be traded for a higher return, that is what we need to consider in real programming. So in many cases, “it's not that it can't be done, it's that people won't do it.”
3. As for the problem you mentioned in the first post, it really isn't a very complicated case, but if you insist on implementing it through batch files, then it really does require some thought. But do you want the program you write, just for the sake of “pausing for two seconds,” to need to load a program that takes two minutes to initialize? That's where the crux of the problem lies.
But why do we still use batch files? First of all, of course, because of their simplicity—most people can write a practically usable program without much thought at all—which really is a great temptation. Another point, which probably quite a few people can also appreciate, is their trickiness—when you run into a problem and think “this can't be done,” only to be told that it can be easily “KO'd” with just two or three lines of code—that kind of pleasure is something many people are happy to experience. Although this kind of trickiness exists in other languages too, none of them make it feel as strong as batch files do. With only a bit more than 10 dedicated keywords available, yet being able to mobilize almost all resources, this contrast is rare in most languages. So even now, I, along with many others, still love batch files, although they are gradually growing old.
Finally, let me apologize to you—after all that, I still didn't completely solve your problem. It's not that I can't think of a way, it's that I don't want to think too much about it

It seems human laziness really is inborn! I sincerely hope you can find the best way to solve the problem; maybe it lies in batch files.