Because for the most part, now that DS is a part of CMS, software delivery is ... separate.
So, for the sake of discussion, let's just assume we're talking about CMS as a single product, which includes SWD, Inventory, DS, PCA, etc.
First, we do recognize the paradigm shift from 6.9, though we can do essentially the same thing. The biggest problem we have currently is the whole TASK concept which, as you mentioned above, and as DS 6.9 did, doesn't verify installation statuses. It fails, or succeeds, and that's that.
So, as a part of this paradigm shift, you get something better, but a little trickier, to manage. You get SWD policies. Along with a Task, these can be very powerful. Several white papers on SWD Best Practices have been written and submitted to Connect, so I'll not even attempt to redo that here, but consider the following as only a decent suggestion. The company hasn't really created a "Best practice" around what you're asking, but I think the following is a good place to start.
Create an imaging task, with a SWD task in it. Currently, this is broken (licensing prevents it) but the company is frantically trying to fix it, and as soon as it's fixed, this is where you should go. For now though, you'll have to make 2 tasks. But let's just pretend for this discussion you don't have to.
So, again, you make an imaging task that reboots to production, then runs a configuration, and then runs a SWD job. You could make some intelligence at this point that, based on position or something, calls a different job for a different set of software, but that's all up to you. We'll just assume it's a job filled with a set of SWD tasks.
These tasks would include things like MS Office possibly with a custom MST for what apps that department needs, or other apps. Maybe, the last task in the job is a full software inventory task, so you can report up to the NS everything on the system. Hopefully, once done, you are in the same boat you were in with a DS 6.9 job, with the computer up and ready to use.
Along with this moderately complext task, you set up policies based on inventory (which you just collected) to ensure certain software types are installed. SQL is very flexible, so you make the filters either based on AD departments, or location, or whatever. The filters serve three puposes: 1) to ensure the software for that department was in fact installed (maybe one was missing from the task), 2) to ensure the software stays installed (since our customers never modify their systems) and 3) for reporting purposes, to show management what is, in fact, installed. Over the course of a couple of days, all the stuff a person needs is trickled down to them if in fact it was missed up front.
Finally, you create reports based on daily inventory that shows the statuses and licensing of your software utilization.
OK - that's very vague, and I'm sure that several companies have better suggestions than this based on size, or demand, or corporate structure, but the ultimate goal of the DS integration into the console was to leverage these other applications. DS inventory was only so-so, and the software installation processes was really really basic (pretty much what the DS copy-file task is today). SWD with conditions and full-scale inventory with NS offers a lot more than you had then. And don't forget patching, and the software portal!
Good luck all!