You are misunderstanding the test cases that Adam referred too have
nothing to do with Chrony other than Chrony happens to be the component
used to test if a service starts and stops correctly

Yes, this is exactly what the tests should do. You are also right about the fact

that it is actually not very important which service is tested here.

I understand Adam's comment as "a sigh".

For F32, we swapped the service already for all our test cases because

the original service had been removed from the installation. We chose

chrony instead because it looked like a service that would stay untouched

for some time - who would want to removea time syncing service, right?

If we decide to remove chrony, we will need to rewrite those tests again,

which will take us time we could devote to something else and the same

can happen anytime soon, which reminds the toil of Sisyphus.

Besides, what good will it do if chrony is removed? It works fine for

RHEL, why does it not work for us?

RHEL is just a frozen reflection in time of Fedora so anything that works on RHEL is irrelevant to Fedora. 

Fedora reflects the opensource environment at a given point in time and that environment changes it's shape roughly every 6 month or so so, so by the time a component hits RHEL it's already outdated and could have been replaced with something else in Fedora.

Fedora users expect to get the latest greatest Gnome desktop environment with all the bells and whistle it's creators envision which is something that you cant deliver in RHEL right.

Take wpa_supplicant for example it works fine for RHEL right but it's about to be replaced with IWD in distributions and I would say now would be the time to look into that and have it in place for F34 which will benefit both IoT and the Desktop environments.  X worked fine for RHEL yet we have replaced it, SysV init worked fine for RHEL yet we replaced it and the list goes on as things continuesly evolve.

Surely you have noticed that when you go to a devconf there in BRNO it's like going to a museum and your like hey we used to do that in Fedora couple releases back how cute they are still working on it and this is going to be hell for them to maintain for 10 years or whatever the lifetime of RHEL is these days.

which could just as
well be done with a service that is already shipped with systemd thus

such as ... ?

Well timesyncd would be a good example, resolved another both components that should be relative harmless to restart thus not affect other test running in parallel on the same image.