Obviously I'm all for code-pub, but I think work needs to be done to normalize publishing the messy/incomplete/piecemeal nature of research software. If you're like me (sorry), you barely have time to get it running once, it looks spaghettirific, and you didn't get to plan it from day one with a requirements doc.
That makes folk reluctant to release; the reception from the software world is often critical (or it's feared to be).
https://fediscience.org/@petersuber/110918041321108927
(h/t to @mlinksva for the timelineboost)
e.g., probably 80% of the time I asked a FOSS-component-related question on a forum or mailing list, the first responses (or if not the first, extra loud ones) were people telling me my approach was wrong and/or I didn't actually need to do what I thought I wanted to. That being in reference to some application-driven development model / goal.
But research often requires poking at things that are oblique / not well-modeled / not-routine. All sorts of "that's not what this library is for" stuff.
The other angle, of course, is that "software written for an academic reason" may also have to be tailored for being read by non-programmers, such as subject-matter experts. It's a lot clearer to follow linear code chunks in an appendix than something that's highly modular or optimized for OOPyness, and that might make a big difference when you need to show a finding to a community that doesn't have the time to learn a bunch of unfamiliar frameworks when they review what you've written.
/eof