Though you didnt mention what is your role in your orgniazation ill attempt to address your question ona few levels.
Note, this is my own personal feelings and ideas, i do not work for microsoft
What you are looking at is indeed Package Managment.
Ill point you to two technologies i think you should aim for:
one is NuGet, the other is Cholclatey.
Powershell works very well with them, DSC as well.
This however will not meke you leave the MSI or packaging dependant packages yourself. Its merely an additional way.
In my environment, Devs used to compile on their own stations and deploy themselves. Ive swapped them all to using a single Source Control platform and a single Deployemnt Platform. My next step is that each of the builds done will result in a NuGet Package that will be sent to a on-premise Nuget sever (very easy to build one) and on it will also be the rest of the packages for software deployemnt like .NET or in the end even MSOffice for example or SQL server and even Oracle Client. As any Setup.exe or MSI based installers that you can install in a quiet mode or with an answer-file, you can package yourself to a choclatey/nuget package.
Then is where i employ DSC localy to deploy the packages, on top of other componenets as i consider them part of the state of the node.
In your customers environment, youre very limited in what you can do. They will not always accept you building a pull server for them or a Nuget Server for them, sometimes it might even cause duplication if they have already implemented a local package management systems like one of options in SSCM. The only option there is a big installation package that has all of the dependencies in it like NET or Oracle Client and chain the installations. That part i dont think will ever change for organizations that are very strict or do not create an internal package repository.
You can sell them the idea that deployemnt via HTTP (as in the case of NuGet/Choclate) is better security-wise then that of a Share hosting the installtion files and giving people access to those. There are numerous package manager solutions that migth be better for their specific needs, youll just have to package yours in more then one way to suit your needs and your customers.
I will defenatly not use any method that is dependant on your customers infrastucture as a means to dpeloy your packages to them. Kinda like taking responsibility to someone elses servers. So things like creating a DSC envirotment at your place and then doing the same at your customers place, i think will not be a good thing.
DSC isnt a deployment mechanism, it lacks severly in the workflow and process management (one of the reasons i use Release Management for TFS on some of my NET projects)
If your customers do have a presence in the cloud connected to their infrastructure, then you could extend your package management solution to your cloud and then share it to them as a service. Each customer and their own ways. wont be easy
You do not need acccess to PSGallery for internal servers, I download the packages im instrested in, and move them to our internal nework and have the servers pointing to that location . Same as i do with PowerShell Help files , saveing them offline and then moving them internally and setting servers to update their help system from that common location via a scheduled task on each node.
Hope this give some light on how i see things.