The key things to understand with AutoInstall is that when building packages, it tries to capture the differences between systems before and after. The captured packages then play those differences back into the systems you deploy them to.
If you capture an uninstall and reinstall
of the same software, the differences before and after will be pretty minor. Indeed, it might not capture much of anything.
In addition, upgrades are often quite sensitive to things like stopping the original drivers (often something that has to be done in a specific order) before modifying their configuration and then restarting them all in some specific way. The before/after snapshots used by AutoInstall do try and deal with that, but uninstall/reinstall cycles are probably the hardest thing there is for it to deal with in that respect.
Basically, AutoInstall is likely to do a much more useful job if you capture one package showing an uninstallation, and then another package showing a reinstallation, and then try them in sequence. Of course, if you capture an installation on a genuinely new machine that has never had the drivers before, that's another case to consider as well.
That said, if the root cause of the problem in the HP drivers is that they capture some machine-specific information at install time and don't like having that information changed underneath them by being deployed in an image, AutoInstall may not be able to help you because it isn't able to capture the logic in the HP installer that does the machine-specific customization.
Chris's suggestion of scripting the manufacturer's driver installation is probably the most reliable technique at your disposal. It may be awkward, but that's somewhat in the nature of the deep system configuration changes that drivers do.