Earlier quoted context omitted.
Basically, you shouldn't rely on techniques like this to protect you against a malicious app. You can rely on techniques like this as one more step to protect you against stupid mistakes, and to help you keeping configurations etc. isolated and make upgrades easier.
I would say it doesn't even do that, given that you're having to give root-level access to an unprivileged user to do it.
I'm not an unprivileged user on any machine I operate in any practical sense, nor are most Linux desktop users, so to me that point is largely moot. That is, even if I'm technically not root most of the time, if I run a malicious app it can relatively easily set up plenty of traps in my home directory to get me to run whatever code it want with elevated privileges sooner or later anyway. So from the outside, having the ability to run Docker does not expose me much more - get my user account, and chances are you get root if you're not completely inept.
That doesn't mean it wouldn't be good to get a better/more fine grained privilege model for Docker for other use cases.
Inside Docker containers, nothing stops us from having everything run as a regular user, though admittedly many Docker containers errs and runs everything as root often for no good reason (especially given that Docker's port forwarding/mapping means a lot of daemons that otherwise at least wants to start as root - even if it could be avoided - have even less reason to be started as root)
But even running as root, assuming an app that isn't malicious, barring me stupidly mounting "/" to a volume in the container, it won't e.g. do things like accidentally deleting [major system directory] (as some app did a while back), even if the app in the container is running as root (which is largely unnecessary, though admittedly done too often, in Docker containers).
It also won't barf files all over my filesystem for no good reason. And I won't accidentally expose ports I don't want to expose. Amongst many other things