I don't think this is a good solution. It is not appropriate to assume anything you don't understand is UTF-8 without giving any indication of a problem. If somebody specifies a charset it is done for a reason. If you ignore it and carry on then you are risking corrupting the data.

PowerShell already has a mapping for 'utf8' and it is used by Get-Content and Set-Content. Rather than invent a new standard here, I suggest this component should be consistent with the rest of PowerShell. Instead of tying to get the system encoding, catching an exception and then pretending everything is UTF-8, it should be the same algorithm as Get-Content. There is a dictionary of string to encoding already maintained by PowerShell as System.Management.Automation.EncodingConversion.encodingMap.

            var typeClass = typeof(PSCmdlet).Assembly.GetType("System.Management.Automation.EncodingConversion");
            if (typeClass != null)
            {
                var fieldInfo = typeClass.GetField("encodingMap", BindingFlags.NonPublic | BindingFlags.Static);

                if (fieldInfo != null && typeof(IDictionary<string, Encoding>).IsAssignableFrom(fieldInfo.FieldType))
                {
                    encodingMap = (IDictionary<string, Encoding>)fieldInfo.GetValue(null);
                }
            }

This dictionary should be consulted first with a TryGetValue, if that fails it should then use the system provider with Encoding.GetEncoding(). Then if that throws an exception, then so be it.

PS> 'hello' | set-content -literalpath 'hello.txt' -encoding 'utf-8'
PS> 'hello' | set-content -literalpath 'hello.txt' -encoding 'utf8'
PS> 'hello' | set-content -literalpath 'hello.txt' -encoding 'utf-80'
Set-Content: Cannot process argument transformation on parameter 'Encoding'. 'utf-80' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name')

That would address the 'utf8' issue in a PowerShell consistent manner and not break by misinterpreting unknown character set encodings.