It should not be necessary to configure a new ingest point at the beginning of each live event.
You can force that to be static and deterministic each time.
1) Set the useStaticHostname to true
2) Always set an accessToken on the LiveEventInput - set it to a static GUID value like
accessToken: "acf7b6ef-8a37-425f-b8fc-51c2d6a5a86a", // Use this value when you want to make sure the ingest URL is static and always the same. If omitted, the service will generate a random GUID value.
I made comments on this in the sample code here -
https://github.com/Azure-Samples/media-services-v3-dotnet/blob/e7ab4a571b0321f3694fbd27c70f27f8282efaa2/Live/LiveEventWithDVR/Program.cs#L221
The rest of your workflow looks fine, but note that you can also pre-create LiveOutputs ahead of time if needed. 10 minutes is just arbitrary as you noted.
The only comment is that if you clean up your Asset and Streaming Locators, you do a cache bust on the CDN for the live to vod delivery. If you do not clean those up, but instead continue to use the same Streaming Locator for the VOD asset, your viewers should gain the benefit of seeing content that is already in their local CDN POP cache. It avoids having to create a second VOD asset and locator which doubles the egress out to the CDN again.