I'm with Martin (mph999) on this one.
When we consider that many even minor changes in Windows (from updates) require a reboot, then this tells us something about the complexity of modern software. Even OpenVMS needed a reboot after some config changes, but then such things are always down to the design of a 'system' as a whole - and the latent comlexity of testing. When one stops and thinks about the design and scale of NetBackup these days, it's a little unfair to think of it as just another Backup Application - IMO, it's so rich, wide and deep now; that really we should think of it as a BOS (Backup Opertating System) (just think how many commands and switches there are!), almost like some OS used to be refered to as a DOS (Disk Operating System) - and there were many other Disk Operating Systems, even on large mainframes, not just MS-DOS. Anyway, they were all cutting edge at the time, and so is NetBackup now.
So, back to Martin's point... If you are experiencing ever decreasing time for manintenance down time, even just a few minutes (for a small system) (sometimes an hour and a half to restart a large environment) to restart the appliaction, then your environment is slowly painting you in to a corner, which is never a good place to be.
To be clear about something, I have yet to some across a "known" situation where a change to a NetBackup application configuration element requires a whole system reboot. It's usually changes to other elements on the perifary (even just at the edge of the O/S that meets the NetBackup boundary) that require reboots. Usually a "clean" restart of the application/system/environment is enough - and remember 'environment' doesn't just mean the master server, sometimes this covers all media servers too.
We've all gone through the phase of thinking - why doesn't that config change take effect immediately - believe me, we all have. I guess it's just something that we've since learned to live with - the benefits of such a wide scope of configuration flexibility outweigh such annoyances.