This is, I agree, potentially confusing to a new-to-AAD developer or administrator. Nitin's answer does a good job of summarizing this but I wanted to add an answer with documentation references.
At https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals it says:
Consider the application object as the global representation of your
application for use across all tenants, and the service principal as
the local representation for use in a specific tenant.
Then, at https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added, it says:
You can manage application objects in the Azure portal through the App
Registrations experience. Application objects describe the application
to Azure AD and can be considered the definition of the application,
allowing the service to know how to issue tokens to the application
based on its settings.
and
You can manage service principals in the Azure portal through the
Enterprise Applications experience. Service principals are what govern
an application connecting to Azure AD and can be considered the
instance of the application in your directory. For any given
application, it can have at most one application object (which is
registered in a "home" directory) and one or more service principal
objects representing instances of the application in every directory
in which it acts.
So, for third-party apps, you'll only have a service principal in Enterprise applications. For first-party apps that are internal, you'll have something in both places - one to define the app (App registrations) and one to allow the app to actually sign in to Azure AD (Enterprise applications). When you define the first-party app in the App registrations, you'll also automatically create an entry in Enterprise apps. If you look at the two entries, you'll see that the Application ID links the two together.