Glad you changed your mind about the maintenance plan wizard - I would hate to be a raw new DBA without it.

I make very little use of the maintenance plan wizard, but that's not because I expect it do do harm (as someone else said, I could do the same harm with an SQL script - in fact I could do far more harm with an SQL script) or to restrict the work that the maintenance plans can do in any unobvious way: it's because using it is a manual process. With a whole pile of servers scattered round the world, many in places where the internet speed is not really adequate for interactive access from the other side of the world, plus a strong desire to get the maintenance jobs set up on initial installation of a new instance of our product without giving the installers scripts that they have to go through manually, I found that using the (SQL2K) maintenance plan wizard meant that too much work was unautomated.

But I did use the maintenance plan wizard to create (or amend) template SQL jobs; it's then trivial to generate T-Sql scripts from the data in MSDB on the template system to create the correct jobs (or amend the existing maintenance jobs) on a new system (all our custmers have the same set of schemas, so they all need the same maintenace jobs, roughly speaking).

For someone with a small number of servers and no high rate of new installations the maintenance plan wizard should be adequate for a large portion of the time. If I were in that situation I would use it. I might want to write some extra jobs, but even so it would save me work.

The only thing that I've wanted to use that the maintenance wizard didn't support was incremental backup, but the way NTBackup breaks the SQLS backup chain it's often not possible to use incremental backups anyway (and even without incremental backups you have to make sure SQL full backup runs right after AD backup if you want a genuine full recovery model on a multi-server domain).