"UniGreek" didn't happen because character encodings already existed that encoded Latin, Greek, and/or Cyrillic separately. Round-trip conversion is a non-negotiable requirement of Unicode, so merging any of those characters was impossible. There were no encodings that treated Japanese and Chinese simplifications of the same characters differently, hence why UniHan was allowed to happen. For similar reasons, we have twelve meaningless kanji in Unicode that exist purely as typographical errors during the standardization of Shift-JIS[0].
Furthermore, the primary motivation for UniHan wasn't to 'clean up' similar orthographies to avoid encoding homoglyphs. It was to stay inside 16 bits of coding space. Unicode was fighting a civil war against UCS, which proposed a 32-bit codepoint space, which would mean 32-bit characters, which the entire industry NOPE'd out of. Turns out, UCS was right, 16 bits was not enough, and the result is that every system that jumped on the Unicode train early[1] is now permanently cursed with improperly handling less-common kanji and most emoji.
For the record, I consider both UniHan and the hypothetical "UniGreek" a mistake. What characters get encoded in Unicode should match what speakers of a given language would consider distinct characters, not what we can arbitrarily merge to fit under a given coding bitrate. The only viable long-term solution for internationalized text was 32-bit codepoints encoded using a variable length encoding compatible with ASCII. We wound up with 20-bit codepoints, but I suspect at some point we'll need to break UTF-16 some more.
[0] This is known as "yurei moji" in Japanese
[1] Windows, Java, and JavaScript[2] all mishandle codepoints outside the 16-bit basic multilingual plane, which were encoded as pairs of 16-bit surrogate values in a special range of non-codepoints. Modern UTF-16 handling is supposed to treat these as single astral characters and reject broken surrogates, but the systems in question retain Unicode 1.0 era quirks for backwards compatibility.
A few years after the Unicode/UCS wars, Ken Thompson and Rob Pike would propose UTF-8, implementing it in Plan 9. This encoding was and is superior to UTF-16 in every possible way - including support for 31-bit code points, which UTF-16 surrogates can't do. UTF-8 isn't mangled by anything except the above programs... and MySQL, which had to add a second "no seriously it's UTF-8 for real" encoding.
[2] ActionScript inclusive. Yes, Ruffle has its own wide string library because of this.