If you are only working with the scopes that a LOCATION OAuth-In app allows you, then the PAT changes can be made almost a non-issue. You don’t need a server. You don’t really need an app as such. Once you’ve got your tokens you can use them just like a PAT and all you may need is an extra API call to refresh your tokens if the access token is more than twenty-four hours old (and you need to do a refresh at least once every thirty days). See here for an example.
It is where you are using the PAT for stuff at the user level rather than an individual location level that you run into issues. Things like capabilities, profiles, drivers, channels and apps are things that belong to users. They aren’t part of Locations. There is a USER_LEVEL principal type for OAuth-In but I can’t get that to play nicely yet.
PATs come in handy for the one-off remote setup of the SmartThings end of the apps, both Webhook and OAuth-In. In theory the SmartThings end doesn’t need to be touched again, but in practice there can be a need to locate or regenerate IDs if something unfortunate happens at the remote end. So a PAT would be needed again. That seems to be where HA has the problem because it expects to be able to do that sort of thing as an everyday routine. It maybe that it is that expectation that needs addressing.