In the medium case its fine, you'll get folks who write code using a 'common' coding style and for the most part switching between them will be not too difficult. I've observed over the years that a noticeable number of bugs will be introduced by people who didn't read the code correctly.
The place it will go off the rails is when you hire 'that guy' (and it always seems to be a guy) who writes lots of code, and it works, but for reasons that only he understands he only writes it on one line. He likes every function to have its own line, that way he can just use the 'down line' command to get to the next function. And he doesn't really comment anything except sometimes in the middle he'll start a comment between the code that does something and code that doesn't. And someone will have a problem and it will be in this guy's code and they will come to you because they can't read that code and they aren't going to check anything in like that.
At this point a number of entirely predictable things happen. Let's name the players, "Crazy Coder" (CC) who has the bizarre style, "New Guy" (NG) who is asked to fix a bug in CC's code, and "Manager Guy" (MG) the person responsible, ultimately, for all the code.
First there is a blow up when NG takes CC's code, runs it through a pretty printer and reformats it into something they can read, fixes it, and then checks it in. CC has a huge fit that their code has been made "unreadble" by NG and they go back, rewrite all the code that had been reformatted including the NG bug fix, except they won't quite get what NG was fixing and so CC's version of NG's fix won't actually fix the problem. Now NG will be have their bug re-opened because their fix doesn't work.
Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off. CC will rewrite chunks of the system to invalidate previous fixes by NG and others.
Now as the outlier, MG might want to tell CC to 'change' their coding style to something a bit more standard. They won't. They will insist either there is a coding style or there isn't, if there isn't then there isn't a problem, if there is then everyone has to follow it. And the coding style dilemma will be served up front and center.
Coding style requirements become the lesser of two evils.