Your approach totally works, but we typically run into the problem of "system administrator has thing that works for them on a couple systems", then it's rather difficult to get everyone using the same tool so that people can interoperate (or bikeshedding about which one has a nifty feature and changing tools every six months) -- or worse, breaking something because they didn't understand how the other tool's process was different.
If different teams want to build their own packages (using whatever toolchain they want, which results in a .deb) and have them hosted on the company repo server(s) - why should they care how the hosting works? Have them supply (usually an upload of some kind) the built (and if necessary, signed) package files, and their job is done.
I know it's hip and cool to treat "devops" as meaning "developers get their hands dirty with ops and we have no separation" but that's a ridiculous interpretation of the concept.
There is a definite and identifiable skillset involved in system and network administration (aka Ops, Infrastructure, or historically "IT department").
There is no reason developers can't learn these skills (I actually went the other way, studied Network Engineering, learnt dev later, now I do both) but it's stupid to assume that just because a developer can install vagrant, that he or she is qualified to run or make key decisions about core infrastructure and services.
I completely agree that developers shouldn't be making ops decisions and have scars to prove it.
I wasn't saying the existing systems are foolproof, but I don't think PPA's add anything to help the problem you're describing.
Ah and I just realise you were originally replying to the bit about "dpkg-scanpackages and a Makefile”!
It could be that I've just not bumped into problems which require them, but I've not found a project which offered features above the set this gives you where the trade-off is worth the complexity. "Everything works this very simple way, there's almost nothing to learn" is very persuasive.
[e.g. Use a Debian mirror to pull from if there isn't a local substitute]
That can (and is) done today - host the compiled packages in a reprepro repo, and add it as a source for apt.
If the package is a backport, apt will upgrade/install it, as it's a higher version than that in the official repo. If the package is from outside debian, apt will updgrade/install it, as it can't find any other package with that name.
I realise you said "prepackaged" but the steps to get a basic reprepro repo setup, and the steps to (e.g.) pull a testing package and build it under stable, are documented numerously online - if the existing options are too complex for the audience you have in mind, I think building (and maintaining) their own packages is not a reality for that audience.
edit: s/of/for/
I think my problem at this point is this:
Every time I have to do manual steps for something that is a one-off [which, let us be honest, I'm not going to automatically configure a deb repo since I only re-do it every few years].
Yes, it isn't /hard/ but that doesn't change the fact it consumes time I could spend elsewhere if I had a standard iso from Debian I can just spin up on a VM or a bare metal server.
Atm, my major limiter is how much time I spend building/maintaining environments vs. programming.
Keeping repositories synced between versions of Debian and architectures is slightly harder but doable.
Best practices for handling uploads from individual developers, making sure all dependencies are included at the same time when a package is published is hard.
Running something like the official Debian unstable -> testing transition of packages (with QA/testing in that loop), and figuring out what rebuilds are necessary is very hard.
What could use some work is the documentation/startup instructions for how to run a Debian package repository effectively (my company has a company-wide repository for internal packages with quality guidelines and a decent amount of review, but this is not without issues). https://wiki.debian.org/HowToSetupADebianRepository exists, but there's ten different tools listed of varying quality and there really, really needs to be a "This is how you need to do it." method.
That said, I really do like the model of "submit source package, server handles the logistics of building it for N architectures".