What is the value added by DRM compared to encrypted streams?

It's a valid point. But there are quite a few differences, albeit not entirely obvious at first glance:

• "Real" DRM systems don't just deliver a content decryption key as AES-128 HLS does. They deliver what is usually called licenses, which in turn also contain a set of usage rights, such as for example an expiry date (useful for rentals), or the ability to play through HDMI, or a constraint on the max resolution you're allowed to watch, and more.
• Real DRM systems typically allow offline storage of licenses, which is useful in those scenarios where playback can also happen offline, or those online cases where you have to maintain state (such as rentals, if for example you play the movie in separate watching sessions).
• Real DRM systems require individualization, meaning that the local license database is cryptographically bound to the device on which it was created. This is to prevent situations where user A obtains legally a valid usage license for content X, and then trivially posts the license database on BitTorrent for everyone to use. User A can do that, but the database is unusable for everyone else.
• Real DRM systems allow revocation, meaning that -- since each device has a cryptographically unique identity -- if a device (or, more likely, a class thereof) is detected to be rogue, then it can be earmarked as unable to obtain future licenses.
• Licenses are signed, meaning that one cannot tamper with one while in transit over HTTP, in order perhaps to extend his rental period or to allow HDMI playback where it was not originally allowed.

And there is more... Also, the above is what most commercial DRM systems have in common, but if you look at individual ones (PlayReady, Widevine, FairPlay, ...) you'll see they also have several individual characteristics that differentiate them from one another and from plain AES-128 HLS.

I can't really better @Guido Domenici answer, but the difference between AES-128 encryption and DRM is immense.

The most obvious example can be seen in the simplicity of ripping off an HLS AES-128 key. The User-agent (browser or app) has to fetch the key to decrypt the content. This is often given in the EXT-X-KEY HLS "header". A simple tcpdump or MiTM SSL proxy (with the certs trusted by the OS) can reveal the key in seconds. It's really no-more than an inconvenience.

In generic terms, with most modern DRMs, a secure plugin or low-level kernel module is responsible for raising a "Challenge Request", containing an identifier for the device, the content id and often a user token. The Challenge is passed, often via an event hook in the application, to the license server that will evaluate the request and on success, issue the decryption key in a signed and encrypted payload. The plugin or kernel module will receive the response and will decrypt the video/audio, passing the media back to the application.

Some DRM solutions also prevent screen recorders.

Another benefit of some DRMs, is that content is rarely completed encrypted and instead employs partial or sample encryption - enough to render the video and audio unplayable. This reduces the overhead required for decryption.