In general, if something wasn't done, assume that it's not a deliberate design decision but lack thereof. It could sometimes be that such a feature was explicitly left out of a design, but more commonly it never reached the 'design' in the first place – it could be way down in the priority list, it could have been only discussed in a hallway and discarded, or it could have been never brought up at all.
In this case, though, the feature "as designed" works differently than what your post assumes in the first place – the OS doesn't try to recognize specific things as video playback, it relies on explicit sources of information (either direct user input, or a program telling it to stay awake).
That is, programs usually have to tell the OS to hold the system awake while some specific operation is happening. For example, in Windows the program can call SetThreadExecutionState(), on Linux the program takes a "suspend inhibitor", on Android it uses a "wake lock".
For apps that weren't programmed to use the OS facilities correctly, Linux comes with CLI "wrapper" tools that do it before running the main app. For example, instead of wget you would run gnome-session-inhibit wget and the system would not suspend as long as that program was running. (Sort of like 'caffeinate' but used in-line instead of being an external on/off toggle.)
Why not a user-typed command in a user-opened Command Prompt App?
As for why wake-locks were left out of cmd.exe and powershell – all we can do is guess and speculate, but the most likely reason is that it would be somewhat difficult to externally distinguish commands that want to finish a specific operation (e.g. format, download) from commands that do not (e.g. if you left an opened git log running and it's just sitting there).
The same goes for graphical apps – there is no externally visible difference between a game that must remain awake and an email app that could be suspended without problems, despite both using the network at the same rate; or between a video player that must remain awake and a picture viewer that could be suspended, despite both being full-screen.
I suspect that more often than not, it would lead to false positives that result in the system staying awake when it should have suspended, and your complaint would just be replaced by someone else's complaint about Windows increasing their power bill.
(This is already a problem with Windows 10, as one of its internal Windows Update services occassionally takes a wake lock and forgets to release it, resulting in the system never going to sleep even though no operation is actually being performed.
But also consider the maintenance costs of features: such a problem is still easier to solve with an explicit wake lock, as the fix only affects the specific program that's broken – whereas if the OS had some heuristics to guess or detect idle/active programs, any changes to fix the detection of some programs would likely break the detection of some others.)
