code formatting is totally bullshit
This can easily be disproven by taking some example code (unknown to the developer), removing all newlines, tabs, and reducing multiple spaces to single spaces, and asking the employee to tell you what the code accomplishes.
it's like colors, some people like it red some other blue that's it
Yep. This is the case for pretty much any programming dispute. Tabs vs spaces, C-style brackets or egyptian brackets, ... But the answer is always the same: Some people like to drive on the left, some people like to drive on the right. Either is fine, but allowing both at the same time leads to madness.
Or, if you really want to use his analogy against him: but using blue and red together makes purple, which means that no one gets what they want.
An executive decision has been made to pick this format. Your employee does not have the authority to override that discussion. End of story. I would not endulge this line of questioning any further.
I'm always open to constructive feedback but your employee's argument is one of hardheadedness, it's not constructive. Don't let them turn it into a competition of being the most stubborn. Even if you win, you're signaling to your staff that being stubborn is an acceptable way of expressing disagreement.
That doesn't mean you can't help him if it's simply a matter of inexperience. Maybe you can find an automated formatter so he can type in his own format and have it converted.
I've told the people I managed that I don't care about the readability of their code before they check it in. I'm not expecting them to fully uphold the style guide at every second. As long as the code gets cleaned up before it's merged into the branch, that's acceptable. I often start from quick and dirty code and only clean it up once I got it working. Some people work this way, and that's okay, as long as they don't skip the required cleanup in the end.
it reduces my freedom
No one has the freedom to do whatever they want. Having to pay the employees reduces the company's freedom too.
The effort required to format the code from the get go will pay back dividends when someone else has to read their code.
Given this employee's remarks, I suspect it's likely that he's complained about other people's code formatting or naming conventions. Point out that others will feel the same about his formatting and naming. Uniformity means that everyone can read everyone's code, regardless of whether it's everyone's personal preference.
it makes code more complicated to read with no added value
It's harder to read for him now because he's not used to it. The more he resists the change, the longer he's going to struggle with it. The decision has been made, it is happening, end of story.
I would focus on the point that the employee has been informed of the new format, and is expected to now uphold it. If they don't comply (or don't put in genuine effort), any delays caused by their pull requests being rejected falls squarely on their shoulders.
Code merge requests have to be formatted with the tool otherwise they cannot be added to the software.
When you say "cannot", do you mean that it's not allowed, or that it's not possible (e.g. a reviewer will always reject the request)?
If it's the latter, that's the stick you need. If the developer does not follow the formatting rules, their requests do not get accepted and any delays incurred from this are their responsibility, which will result in a bad performance review.
If it's the former, then you're really relying on everyone to willfuly partake in the system, which only works if everyone does so. You're currently dealing with someone who's holding out. It's possible that he's holding out specifically because he knows that you don't enforce it but only ask.