Acceptable Domain Logon Times

Assuming the rest of the logon time is similar, 30 seconds is pretty good. I generally don't focus specifically on one section unless it stands out as significantly slower than the rest of the boot process, either. As a quick aside, I would say that on reasonably middle-of-the-road hardware in today's sense, anything quicker than 2 and a half minutes from POST to logged in is quick, and anything in addition to that needs to be considered in the context of the environment (are you doing a lot of GPP, whcih slows down logon? Running logon scripts? Lots of services to start, especially antivirus, app virtualization, etc? Do you have a baseline to compare this to?).

As someone who deals with a lot of what you're questioning now as a day-to-day job, I would say one of the most important things to do when you're considering boot performance on client machines is to have a reasonable representation of the hardware in the environment (as many of the models you would expect a user to have at their desk as possible), and the image you expect to push out to those machines, as your launching point for starting to clear the fog on your own environment's performance numbers. Using xbootmgr to take boot traces, you start by seeing what you have pushed to the client machines and how it is performing on the hardware you have in it's current form (taking 5 - 10 traces to normalize times is a good idea). Then, you look at ways to shore up those times, looking at things like what can you delay, or what can you remove; are you defragmenting the disk well, and is superfetch / readyboot working properly, as examples.

Once you've gone ahead and tackled the kinds of things that you can change or clean up, you re-push the new image with changes down to the client machines, and you re-test with the same methodology, noting the (hopefully) faster boot times. Thiose are your baselines, and you keep those handy for comparison. Any time you change your hardware models in your organization's baseline, you need to re-test and make sure your baselines are up to date with the new hardware. The same thing holds true for your image - if you change that, you want to re-take the numbers so you have them for comparison. The real takeaway is that guesswork is just that - inaccurate and as likely to be wrong as it is right. Having hard numbers to compare in your environment with what it looked like when it came out of the oven, versus what a user might be seeing if you trace their machine in it's current state, is the only way to actually be able to answer those questions with hard data that can back up your findings.

Then, and only then, will you know what your image and domain configuratiion do to boot times, and be able to answer the questions you are running into right now. In general, though, boot performance is more dependant on things like disk fragmentation, poorly performing antivirus software, driver delays, or network issues than you usually see with group policy performance delays - it's not that they don't or can't happen, they just usually aren't an issue in the overall picture (and just as with anything, lots of policy settings coupled with lots of preference items, especially if your policy calls lots of group policy extensions or re-ACLing of filesystem or registry locations due to what you set, can indeed show performance delays that you need to accept can happen).