The main barrier at the moment, is that sage patches many dependencies. It is better to upstream those patches, not only because it's good engineering practise, but also because it's unlikely that Debian policy (in practise: the admin, infrastructure, and security teams) would allow us to include (e.g.) a duplicate maxima-with-sage-patches in Debian, just to satisfy Sage.
OTOH if you "just want to" create .debs, the task is much easier. But then there's no chance of it entering Debian officially.
My counter argument is that we want to expand Sage's user base beyond a small core of researchers, and improve its usability as a Mathematica replacement for students and some scientists who are less interested in things like bleeding edge combinatorics research (they might be but not necessarily the majority). As a Mathematica replacement Sage isn't there yet, but it's good to get a head start on making easier to package and install, as part of that effort. Like for me, if it can solve some differential equations for me and do some integrals I don't care if the version I got through apt is a couple years old.
As for the upstream issues part of the problem there is that some of the upstream dependencies of Sage refuse to accept patches needed for them to integrate with Sage. That's a long story. I think the best approach there, which has already been tried in past approaches to patching for Debian, is to maintain Sage-specific forks of that software that include the necessary patches (IMO they should also be swappable with the originals via update-alternatives if possible). As far as I know there's nothingf legally preventing that, but more the effort involved in maintaining a fork and a package for that fork.
In the long term, I think, it would make sense to completely replace and rewrite some of the code that these external dependencies are used for. But in many cases there's an enormous amount of work involved, and that would only be possible with significant funding. And quite possibly not worth the effort compared to other ways that effort could be spent.
> Debian moves to slowly [..] My counter argument is that we want to expand Sage's user base [..]
Beyond that - "too slowly" applies only for "Debian stable"; and users that are OK with less stability can use "Debian testing". Usually this is quite bug-free; things only enter testing if it's been in "Debian unstable" bug-free for 5-10 days.
It's also much easier to get your software into Ubuntu, if it's already available in Debian testing/unstable - and that would likely expand your user base quite a lot.
> some of the upstream dependencies of Sage refuse to accept patches [..] [we could] maintain Sage-specific forks of that software [..] swappable with the originals via update-alternatives if possible [..] [or] completely replace and rewrite [it] [..]
Yeah, the situation is complicated. We could try different approaches for each dependency too, and perhaps some of them will change their mind. Debian does (on purpose) make it quite high-cost to maintain forked packages, in the sense that we would have to argue our way through many layers of admins of different systems, to incentivise us to get patches accepted upstream.
When you have time, could you write up the details of the situation on your end? Something similar to the wiki page I posted earlier - or you could also just edit that directly, if you wish.