Pierre,
It was a case of SPN as hinted by you. But the errors from the pre-requisite checks didn't have any information pertaining to that. MS and other articles mentioned that the kerberos error that was seen in the logs could be ignored.
The issue was due to a duplicate spn assigned to the adfs server object in top level domain.
The error received during the pre-requisites check was misleading. Running the diagnostics as outlined in the link below pointed to a possible SPN issue.
There are three domains in the environment - contoso.com is the top level, domainA.contoso.com and domainB.contoso.com are the child domains. The adfs servers are located in the top level domain whereas the service account is located in the domainA.contoso.com.
When duplicate SPNs were checked through the generic command "setspn -X" it was run from the domainA.contoso.com and didn't find any duplicates. That misled us to believe no duplicates existed.
After the diagnostics pointed to a possible duplicate, ran the following command for every domain
setspn -T * -T contoso.com -X
setspn -T * -T domainA.contoso.com -X
setspn -T * -T domainB.contoso.com -X
Sure enough, one of the adfs servers had host/sso.contoso.com SPN assigned to it. Once that was removed 2022 server was able to join the 2012 r2 farm.