Best-practice models for "research" code?
I think the key to understanding research code for industrial software engineers is to accept that you are typically not building a product. You do not have customers as such. You are building software to prove a point.

As such, the majority of code that you write as a researcher is more akin to the throw-away prototypes and mockups that you (in industry) often write in the early phases of a project. As you are certainly aware, even in industry these mockups have quite different properties than the final software. They primarily need to:


Have exactly the features that you want to show to the customer. Not more, not less. Typically, all the boring standard features for the domain are omitted.
Need to get done quickly. Both you and the customer know that the prototype will be thrown away anyway, so it does not matter whether the code is maintainable.
Need to be easy to extend and adapt, optimally live during the demo.


Essentially the same properties are also useful for most throwaway research code. You do not want to build features that you do not need. You do not want to waste time writing e.g., maintainable code if you know that it will not be maintained. You want to use an environment that reduces the amount of boilerplate code and setup, and which maybe auto-generates a lot of code for you that is "good enough" for your demonstrator (Ruby on Rails and its scaffolding features come to mind).


  My career progression is dependent on me writing "bad" code!?


No, it depends on you writing code fit for purpose. Just like in industry. In industry and academia nobody applauds you for software qualities that are not needed. Try to reconsider what the point of the code is that you are writing. If you plan to release your code as open source software and you expect it to be picked up by other people across the world, then go nuts - use all the engineering techniques you have also used in industry to build the best product you can. If your goal is to evaluate this one algorithm or principle for your conference, and then throw away the code, then you can also live happily without writing a single unit test without feeling like a fraud at all.

EDIT: of course this does not mean that it is acceptable to write code where you are unsure whether you have implemented said algorithm correctly. Ensuring that what you have indeed shown what you claim to have shown is mandatory, especially in research code.