Please note that I don't ask how. I already know options like
I want to ask why doesn't
cp implement a progress bar, at least as a flag ?
The tradition in unix tools is to display messages only if something goes wrong. I think this is both for design and practical reasons. The design is intended to make it obvious when something goes wrong: you get an error message, and it's not drowned in not-actually-informative messages. The practical reason is that in unix's very early days, there still were teleprinters; that is, the output from programs would be printed on paper, and you don't want to print progress bars.
Whatever the reason, the tradition of only displaying useful messages has stuck in the unix world. Modern tools have sometimes introduced progress bars; in rsync's case, the main motivation is that rsync is often performed over the network, and networks are a lot flakier than local disks, so the progress bar is more useful. The same reasoning applies to wget.
This is one of those marginal things where there are arguments for and against adding a progress bar option to cp. The main argument against, is that you may not know ahead of time that you want to know the progress. Ctrl-T/SIGINFO is available on BSD for this purpose, and if that becomes available on GNU/Linux platforms, then there might be more reason for that to trigger progress bar logic in cp. In the meantime a more general solution is to use a separate tool like coreutils viewer to display the status of any process on the system.
In the unix world, each tool is designed to do one job and do it well. Why would
Tangentially, most shell programs are designed to have their output piped into other shell programs. The only output they are likely to give is things that would be useful to parse out in the next command in the chain. Programs like
Always expect to combine tools to accomplish your desired effect.