Apparently gameObject.transform.eulerAngles is accessing a copy, so changing it shouldn't do anything, and in fact using .Set doesn't work. But why does =new Vector3 (..) work?
EDIT: Given the answers - I think I should update the question. What seems inconsistent to me, is the fact that "new Vector3" works as a setter the way I would want it to, but not using "new" and .Set doesn't. It doesn't seem very intuitive that "new" is understood as "ah, he's trying to set this property of a property" that way want - the choice of word doesn't seem very intuitive at least.
I suppose it makes sense in the ".Set" case - you might want to intentionally use the .Set of the Vector3 returned. Essentially, it might be useful to interpret A.B.Set as (A.B).Set, as this is the "natural" way to interpret it, as opposed to some other "ordering" (which could symbolically be expressed as A.(SetB) or something like that).
But in the other case - I don't know why omitting "new" doesn't work. It would seem like a natural choice to interpret (A.B.C)= as "he wants to set the property" - what else could be intended by this? I can't think of a reason why someone would want it to do something else than what happens when you add "new" - i.e. assuming that A.B gives you the copy of the property B of A, and assuming it's not some sort of simple object like a Vector3, why would you want to set this copy of the property to something? In what scenario could that be a useful, efficient way of doing something?
But thinking about it again, I suppose the reason might be the same as with .Set -the code A.B.C= is simply understood as ((A.B).C)=, because that's the most natural, basic way to interpret it, is that right?
transdorm.eulerAngles
returns a copy, therefore writing to it must also write to a copy. But that's not required by how C# properties work; in fact it would be unusual API design to expose a setter method that can never change the underlying state (in most such cases it would be clearer to not expose a setter) \$\endgroup\$