Not at all. In fact, our experience has been exactly the opposite.
See the discussions here: categorizing models in own files instead of models.py and How to separate models.py into django app by folders & sub-folders?
For a discussion from the opposite perspective, see Combining Urls, Views, Forms, and Models into fewer files
“Code to interact with the api” - I’m assuming by “api”, you mean a REST-style HTTP interface accessible to the outside world. If so, keep in mind that your api are views. If code receives an HTTP request and returns a response, it is, by definition, a view.
By having one more set of “entities” that you need to understand and manage. You’re (needlessly) adding more information that needs to be remembered and understood. You’re adding another decision into the development process that doesn’t need to be there.
The entire Django documentation. The Django tutorial. The Django Girls tutorial. The fact that the Django docs themselves don’t address these issues - and some of the side effects involved with them - is itself an indication that the developers of Django don’t consider them necessary.
Sorry, that’s still too much from my perspective. You will never convince me that there is value in separating out individal models or views to that degree of granularity. I’ve got too much history dealing with systems consisting of thousands of files to ever want to go back to a situation like that. It’s just not worth it.