This sounds like a bug or oversight in Unity.
Normally a line like this:
will create a copy of the current material being used, unique to this object, specifically so that whatever you do to the material next won't spill over onto other objects sharing that material, or alter the source asset in your project files.
(You can use the
.sharedMaterial property instead to avoid this copy if you're being careful and want to control how many material copies get instantiated)
.material property on UI renderables like
Image does not have this copy behaviour.
hands you the actual original source material the object is currently using, without copying it.
And if you didn't set a custom material on the UI, then this gives you a reference to the global default UI material and lets you change it in code, even though it's treated as non-editable in the editor interface. It seems like mucking with this should at least generate a warning.
Fortunately, changing the material directly is not the preferred way to apply colour changes to UI (which might be why this seeming inconsistency slipped through). Instead, most UI renderables expose colour properties for this purpose, which can apply tints on top of the material colour, letting us draw lots of differently-coloured UI in batches without lots of costly material changes.
So you'd do something like:
myButton.GetComponentInChildren<Image>().color = translucentColor;
That way you tint just the button's backing image, not everything in the UI!
To fix the default UI material, all I had to do was close my project and re-open it. It seems Unity doesn't serialize changes to the default UI material (fortunately!)