The most blatant differences are surely in things like packaging and update delivery, but in a sense, these things are what you rely on the vendor for (if they can be bothered to fix stuff, that is). Meanwhile, having all the infrastructure hooks in place is going to be more work for the "regime" in question: how the software uses the existing authentication systems, and so on.
Even if it's not the case now, over time the goal of the distribution vendors should be to make their products fit in with the minimum of local effort. Once upon a time, having huge numbers of local customisations and packages would have been the norm, but effectively saying that "Red Hat's package for XYZ isn't as good as our local package" can be regarded as making a bold claim indeed, at least for software where Red Hat can bring a lot of top-level expertise to bear.
I've worked in places where the "regime" even felt the need to have their own special Windows distribution, much to the annoyance of colleagues who found stuff mysteriously disappearing and having "fresh" stuff copied in on a regular basis, so if the support burden starts to stack up to "double the work", my experience tells me to review what the nature of some of that "support" is. I can well imagine that an mindset of maintaining lots of "special" software (from the days when people had to deliver stuff in a heterogeneous environment where the target platforms - stuff like Ultrix, IRIX, HP-UX, Tru64, SunOS, Solaris, AIX - had no decent repositories of their own) persists in many institutions and is not always adequately reviewed.
But anyway, the deployment of different distributions shouldn't be radically different. Although vendors may see some benefit in having things that way, or selling management tools to smooth over the cracks, it's certainly not in the spirit of giving end-users the choice, which is what many people see (perhaps implicitly) in Linux.