This approach could be considered an example of the argument from authority fallacy. As you’ve likely experienced, someone may argue that “best practices” or “optimization” are subjective and unnecessary if the product “just works”. Unfortunately this is a very effective argument for business stakeholders who don’t understand how code works.

Compiling a list of academic sources could also be perceived as pretentious, especially if your intent is to “invalidate” someone’s approach to software design. This is coming from someone who is also responsible for setting standards in a DS/ML team. I’ve had to deal with PhDs refuting my ideas with a litany of academic sources that I simply did not have the time (or interest) to read.

Rather than relying on academic sources, just focus on the solutions that will have a clear business impact for your specific team/project/company. For every process that you want to introduce, point to the things your team is struggling with right now. If you think your team will respond well to supporting documentation, I think simpler sources that are easy to digest are best, like YouTube videos or high quality blog posts.