UTF-7, UTF-8, UTF-16 and UTF-32 are simply algorithmic transformation formats of the same coding (codepoints) of characters. They are encodings of one system of codification of characters.
They are also algorithmically easier to navigate forward and backward than most previous schemes for dealing with character sets larger than 256 characters.
This is very different than the generally country- and sometimes vendor-specific codification of glyphs. In Japanese alone, there were a ton of variations of JIS alone, not to mention EUC-JP and the codepage-oriented transformation of JIS that DOS/Windows machines used called Shift-JIS. (To some extent, there were algorithmic transformations of these, but they were not particularly simple and there were vendor-specific differences in characters that were available. Multiply this by a couple hundred countries and the gradual evolution of more sophisticated font systems (post greenscreen era), and you had a real nightmare.
Why would you need these transformation forms of Unicode? Because a lot of legacy systems assumed sequences of ASCII-range 7 bit characters, so you needed a 7-bit clean solution safely passing data uncorrupted through those systems, so then you needed UTF-7. Then there were more modern systems that could deal with 8-bit character sets, but nulls generally had special meanings to them, so UTF-16 didn't work for them. 2 bytes could encode the entire basic multilingual plane of Unicode in its first incarnation, so UCS-2 seemed like a reasonable approach for systems that were going to be "Unicode aware from the ground up" (like Windows NT and the Java VM); then the extensions beyond that necessitated additional characters, which resulted in the algorithmic transformation of the 21 bits worth of encodings that were reserved by the Unicode standard, and surrogate pairs were born; that necessitated UTF-16. If you had some application where consistency of character width was more important than efficiency of storage, UTF-32 (once called UCS-4) was an option.
UTF-16 is the only thing that's remotely complex to deal with, and that's easily mitigated by the small range of characters that are affected by this transformation and the fact that the lead 16-bit sequences are neatly in a totally distinct range from the trailing 16-bit sequences. It's also worlds easier than trying to move forward and backward in many early East Asian encodings, where you either needed a state machine (JIS and EUC) to deal with the escape sequences, or potentially move back several characters until you found something that was guaranteed to only be a lead byte (Shift-JIS). UTF-16 had some advantages on systems that could chug through 16-bit sequences efficiently, as well.
Unless you had to live through the dozens (hundreds, really) of different encodings out there, or had to build systems that supported multiple languages in different encodings sometimes even in the same document (like WorldScript in the older MacOs versions), you might think of the unicode transformation formats as unnecessary complexity. But it's a dramatic reduction in complexity over the earlier alternatives, and each format solves a real technical constraint. They are also really efficiently convertible between each other, requiring no complex lookup tables.