That's quite a simplified and antagonistic comment.

Data scientist have their own problems too, like crappy data (if any) and unclear business objectives. This usually means fast iteration at all costs. That's why Python or R are the languages of choice, which are not precisely the most amenable to deployment. Now, think about their KPIs vs yours and everything falls into place.

I view the job of the MLOps framework as essentially a contract where "You place your messy code that does X here, and we'll take care of turning it into a retrainable, resilient, secure API endpoint without any extra fuss". This requires the software engineer/dev ops person to think through ahead of time what the data scientist will need to do as a part of their process and templatize it and form a good abstraction. The problem is that the abstractions are often leaky so there is some constraint that needs to be put on the data scientist. This also requires the MLOps engineer to work on new feature development to form a new abstraction to handle the new features. "Oh you want to do active learning? What does that look like?".