Connected apps can be installed in more than one org. The definition (where you manage things like the connected app name, the oauth scopes, can see the consumer key and consumer secret, digital certificate to use, etc...) lives in a single org, and it should generally be a permanent org.
The connected app policies (how long access tokens are valid for between calls, OAuth usage, users self-authorize/admin approved users are pre-approved, etc...) live in each org that the connected app is installed in.
This behavior, a request using a connected app not installed in a target org pre-adding the connected app to the org, is useful for things like the Salesforce-provided Data Loader or the developer workbench. You don't need to explicitly find/add/install the connected app in each org.
It's also useful for general integrations because it means you have a single point of management (and a single consumer key/secret pair to manage). If you have the consumer secret and want to integrate with a new org (a new or refreshed sandbox, for example), you only need to send the request to
https://test.salesforce.com and have the user provide appropriate credentials for that org.
I think the key part of the equation here is that OAuth ends up requiring both the consumer key and the consumer secret (or, in the case of the JWT Bearer flow, a digital signature to sign a request using the private key of a cert). If an external source can provide the consumer secret, then the request is assumed to be legitimate (this is why it's important to keep your private keys/consumer secrets very tightly controlled).
Authorization is largely controlled by the consumer secret (or digital signature).
Authentication primarily depends on the user.
It takes both parts (Authorization and Authentication) to be able to do anything in the target org, so as long as the secrets remain secret, this behavior should have no adverse security implications.