When you create a new Sandbox the final step is to [optionally] select an Apex Class to run in the Sandbox post-copy.
Anything you can affect in your configuration through Apex you can script in this manner (e.g. create test records, set user logins, etc).
I apologize in advance for whatever opinion follows, but these are my opinions from my experience.
Targeting the edit of the question - I would recommend researching the other configs you want to change and how to manipulate them with Apex. If any of your updates can be handled in Apex I recommend that solution as it is the most robust. That being said, the items you reference are not available in Apex (yet?) so you'll need to get...creative.
Theoretically you could write one or several Selenium scripts to get the job done. Selenium is a web browser automation tool most often used for automating front-end testing of web applications. Courtesy of Salesforce' consistent design of their classic admin interface you could write Selenium scripts that would last for some time. (I've shied away from the LEX Admin Interface so I cannot state with any certainty whether the design changes or not or with what frequency or significance.)
However, I would not recommend this solution unless you're an extreme Sandbox user. Most orgs I've encountered will update their ongoing Sandboxes (of which they typically have 2-3) on an approximately monthly cadence with post-refresh work taking an hour or two at most. When working on a team I've always maintained an Refresh Update Log that lists the manual steps one needs to take post-refresh and added to it with each new Sandbox. ("Oh yeah, I forgot we changed ABC in prod last week. Adding to the Refresh Update Log.") If you maintain diligent change logs for production you can quite easily scan through your month of updates and add necessary steps to your Refresh Update Log.
If you choose to go with Selenium you'll face a potentially significant upfront investment (especially if you have to learn how to use it first or hire an Automation Contractor) with ongoing maintenance. Depending on your situation, it may be worth the time but I doubt it - conceptually I'm thinking you'd need to be performing daily refreshes or refreshes on dozens of Sandboxes to warrant this cost. If that is the case it might make more sense to use your Sandboxes almost like git branches - where you merge small changes from various "user story boxes" into a "feature box" into a "staging box" and finally into production. Then you'd only need to consistently refresh your staging and/or feature Sandboxes since U.S. Sandbox changes would be very targeted.