We differentiate so that it's easy to know what's in scope of the threat model and what's out of scope.
An external interactor is something that the component(s) we are modeling interact with, but which we do not want to cover in this threat model. A process in a threat model represents a component (or collection of components) that we do want to cover. When someone looks at your diagram, they'll very quickly know what's in scope and what's out of scope if you use these two denotations.
For example, if we are modeling a web browser and that browser does DNS lookups, we may not be interested in modeling the DNS server. As such, we can denote the DNS server as an external interactor. However, we are interested in the behavior of the web browser, so we denote the browser as a process.
We need external interactors because they provide input to the component that we are modeling. In the case of the web browser, we are not interested in modeling the web server, but we do need to ensure that the web browser properly handles data received from the DNS server - for example, DNS names with 64 characters in a (sub)domain (between two dots) have historically caused browsers to crash. If we leave the DNS server out of the diagram, then we are also leaving the inputs from the DNS server into the web browser off the diagram. In the case where we are modeling a complex server application, and the client application is out of scope, if we leave the client application off the model then we miss the opportunity to discuss authentication and authorization controls around the client-server interaction.
We also need external interactors because they receive output from the component we are modeling. If we leave the output off the model, then we lose the opportunity to discuss the content of these outputs, and that they are correct.