We need a process like "Create online race"--- "Select track"--- "Select cars"---- "edit parameters"---- "drive"....
Putting an UI on top of things is not always *that* straight forward as people always think. When adding an UI/ wizard/ process on top of an existing piece of code, you need to investigate several paths. For example:
a) Opinionated path
Basically this means, you skip options, preset values and so on on *your* (whatever that means) opionion. This results in a streamlined process, but tends to be more strict and cause some users to have the need to exceed these boundaries set by the process. This basically puts *some* features in a jail, rendering them on some situations not usable at all and require "logical backdoors" to manipulate them anyways.
And adding these backdoors (not in a malicious way, more like a ripcord for extra features) makes things quite difficult to handle, especially when a user as a result mixes the streamline process and the ripcord.
Example:
You get an UI for the rfm files. But the UI allows you to edit rfm files also on your own. What will the software do when you set an option the UI and in the manual files? Overwrite them? Ignore the UI? Or does the UI does not allow own edits on config files at all? But what with the people relying on by-hand-edits of these files?
b) UI of UI of UI (aka making things even more complicated...)
You basically try to add an UI/ process for all mechanisms. This does not guarantee you reach user satisfaction as desired, as the nesting of steps/views/dialogs will make the whole process more complicated. Basically you end with an 1:n of the original process, which might be an by-hand thing, but at least is always the same scheme for most of the situations. Keeping these UI steps together in an user friendly way without ending in an UX nightmare is quite an challenge.
Example:
You need an UI for the "rules" (rfm, basically), but also one for the settings not present there (like weather, grip). Also you need content views, but as there is no mapping between steam workshop items and the actual content, you need some place do define this, that, for example the UI knows that Steam ID 705367165 contains Matsusaka 2015, with several layouts. Additional, this needs to be adapted constantly for each version. Also you have options which require to interact with the running server (e. g. content unlock), so you are not entirely finished with creating an "package" (not like rfcmp, more like a finished and ready-to-use-server) at all.
c) You keep things at it is
To make clear, the current process is way not perfect. But, when all required information are present, you can achieve the goal wanted. But the hardest task here is to get all the required information to know what steps are needed to achieve that goal. In the past, rF2 tend to lack crucial information, but nowadays for the most situations, there is documentation present. Somewhere. It is clear that people nowadays are used to software and apps abstracting all the nasty work below. And if the "below work" (like here for hosting) is missing, users have a steep learning curve to achieve the goals.
Additional disclaimer I: Money
To implement stuff like this you need quite a amount of PD do develop. And how should this be paid, as there are
people that tend to complain about new paid content aswell? For people running servers *a lot* this is not interesting, as they are used to it and work with existing documentation. And I am quite sure that many of these people added their own tools to handle some of the process by themselves already. So based of the already quite small bubble of rF2 the effort required to implement these featureset for an even smaller subset of people I don't think this is desirable form an economic standpoint. Lets assume for a second such an UI/ process was implemented. What will be the "leading" process? Plain by hand or by UI? In the worst case, this results in two processes in need to be maintained. And everything needs documentation and updates.
My two cents as a conclusion for this monologue
And I can tell you:
As somebody who invested almost three years in implementing *this process* (with some close-to-end-user-readiness results*), you have a high amount of effort needed to "translate" features from "by hand" to UI, with the need to leave *some* features out at all (e. g. content unlocking) which simply requires more steps than an (server side) UI can handle. I am quite sure that S397 is more willing to invest time nowadays more efficiently in topics with an higher urgency.
----
*Off-Topic: That project failed horribly, as almost nobody used it. At the peak it had a single user. Even as it had (imo) quite an potential in supporting server admins in automating several steps of the whole process.
Funny, it's almost on the day two years ago when I published that project... 
