My argument is that the URL address for the HLS stream you access is not in clear text in the html code youtube sends you. Javascript code is executed to decode it (which changes constantly, hence the need for youtube-dl to be updated constantly) and that is a form of DRM which youtube-dl breaks.
In that case every OSS project is in some way DRM:ed since they require a compiler, interpreter or some specific instruction set to run. That is not at all how the term DRM is used, and if you want to think of it that way you should also know that when speaking to others they have another definition of what DRM is.
As I said it is as encrypted (no less, no more) as all other https traffic. Please note that normal https does no verification of the client, the client verifies the server not the other way around (client verification is of course possible but almost no public sites use it). So the encryption in this case verifies that the content comes from youtube or other sites that it supports but youtube itself does no attempt at verification of the client. This is in contrast to real DRM where the content is encrypted in such a way that it is hard to decode it without running the Content Decryption Module, which are proprietary plugins and that can check HDCP and similar ways to only allow playback on "trusted" devices.
