What are the real benefits of using Salesforce DX?
Yes development could be done before. But it took discipline to get the code in version control consistent with the code in orgs. In SFDX version control is the "source of truth".
Subjectively, SFDX is less frustrating to work in and more productive. We now have our Jenkins builds using new scratch orgs rather than recycled developer edition orgs and are pretty much using a scratch org per branch per developer. As we develop managed packages, being able to develop in an org that has the namespace set helps (in most but not all cases), saving a lot of hassle (e.g. only discovering namespace bugs after packaging). Packaging2 will be based on the SFDX format. The "push" model of transferring code to the org works pretty well (including the propagation of deletes); having the fields separated out makes sense; having zipped static resources unzipped makes sense. And the VSCode tooling is pretty good as is the Illuminated Cloud tooling and the SFDX format is where the tooling investment is going to be in the future.
But yes, SFDX doesn't fix everything e.g. the inherent slowness of remote execution and the very poor debugging tools remain a frustration.
Personally, I would hate to go back, and the move over wasn't too painful.
(The hardest part, if you already have version history, is to preserve that history when you transform your projects into the new format. We burned quite a lot of AWS time doing that conversion, and one of our engineers had to learn quite a bit more about Git than most people ever need to know to lead that work.)
I find that DX is easier to work with. It doesn't depend on the developer knowing what/how to edit the package.xml file, for example (unless you are moving from the old format).
A huge gain, in my opinion, is that the pull and push commands seem to retrieve and deploy only the modified metadata (I might be wrong here). The old model retrieves and deploy everything instead, so DX should be faster than retrieving and deploying with the MDAPI (depending on what your setup is, an IDE plugin like Illuminated Cloud might be able to send a package.xml with just the metadata you want to retrieve or deploy too, but then again: you'd need an IDE and/or a plugin for that, whereas with DX you just need the CLI).
This isn't beneficial only to folks who work with managed packages, but Salesforce customers with big orgs and customizations as well. It feels great to be able to create a scratch org which is similar to production or QA in a few minutes, for example. Not only that, but be able to do this from within the CLI instead. This could also be a security gain, since a developer will not need access to production just to create a sandbox.
For me, there are three major advantages:
1. It makes you modularise your code
You might have your existing codebase working in what you conceive to be separate modules of functionality. But, once you split them up into DX packages, you can suddenly notice stray dependencies going where they shouldn't.
We all like to write well-engineered code, but have a tool to call you on it is really helpful.
2. It brings build processes to the masses
Yes, you can make yourself a nice process with Dev Sandboxes and automation tools. But many people working on SF can't invest the time in setting all that up. DX makes it a lot easier to get there. So, it's more attractive if you're not coming from a well-oiled existing process.
I work in a consultancy, so we don't have the time/budget to make a build process for all customers - only the ones whose complexity justifies it. DX lowers the bar for how difficult it is to do that, so we can do it for more customers.
3. Unlocked Packaging is way more flexible than old packaging
Packaging is really nice, and unlocked packaging gives us the freedom to: share a namespace between packages, remove items from a released package, etc. It generally means that you don't have to make irreversible commitments in your package design.