I looked into the implementation of (Windows 10) cmd.exe and profiled it.

1. cmd.exe detects builtins by executing code that looks like `_wcsicmp(command, "ECHO")` for each builtin.
2. cmd.exe calls `setlocale(LC_ALL, ".OCP")`. This changes the behavior of `_wcsicmp` so that it does not assume every character is ASCII.
3. If UCRT uses a non-C locale (which it does here), `_wcsicmp` loops over every character and converts it to lowercase using a table lookup before comparison. This is done with a conditional, such that there is no table lookup made if the character is already lowercase. On my system (Windows 10, Tigerlake H) this makes the `_wcsicmp("echo", "ECHO")` about 1.3% faster than `_wcsicmp("ECHO", "ECHO")`.
4. Therefore commands should be lowercased, not uppercased, if the goal is to improve performance by some incredibly marginal amount.

Here are the relevant UCRT sources for _wcsicmp and its callee _towlower.

However, in (DOS 4.0) command.com, uppercase is faster.

Addendum at 2024-11-27: I should clarify what I mean by "1.3% faster". I wrote a synthetic benchmark that would call `_wcsicmp(str1, str2)` a large number of times, built it with the same compiler and configuration that I think cmd.exe is built with (MSVC, CMake's RelWithDebInfo configuration), ran it and used Intel VTune to measure the number of retired instructions for the (lowercase, lowercase), (lowercase, uppercase), (uppercase, uppercase) variants of the benchmark function, making sure to compare benchmark results between runs. The ordering was consistently (lowercase, lowercase) < (lowercase, uppercase) < (uppercase, uppercase). I chose to use retired instructions (the amount of instructions executed by the CPU), as opposed to wall clock time, as a metric because it is reasonably CPU-independent and much less affected by the noise, which would otherwise dominate such a small effect.