Indeed, while I’m not sure of the current practicalities with TTN, this is essentially why there is a distinction between the network server’s key and the application server’s key.
I am not 100% sure that a private handler mitigates LoRaWAN security: Can the Network Server generate the AppSKey? which describes a limitation in LoRaWAN 1.0.x, as currently used by the public network.
First that is only even a question if using OTAA, a protocol which doesn’t ultimately solve most of the problems that people hope it will when they decide to try using it.
But even in the context of it, there’s no real reason proposed why your own private application / join server shouldn’t be trusted to have the network keys of your own devices. For that to matter you’d seemingly need to have some very odd set of business / trust relationships between entities managing the different pieces, almost as if you were “renting” the nodes and wanting to make sure the customer couldn’t throw up their own gateways and network server and get the data without you. While in TTN, having the “customer” contribute extra gateways is explicitly encouraged.