It entirely depends on the shader you’re using. Most shaders combine the color with the incoming texture and some even double the incoming value. In the end the color is always clamped between 0 and 1.
RGB colour components must be between 0 - 1. Your original code is not a valid colour so, as @Jeffom pointed out, there is no defined behaviour in your case. The “light blue” colour you see is effectively arbitrarily chosen (in other programming environments, it would have thrown an exception).
The problem you need to solve is how you came to derive the RGB component values listed in the first place, and to ensure these are normalised to the 0 - 1 range.
A value of 1 on the final, rendered pixel means it should be the brightest possible, so yes, you are right. Another color with clamped values would produce the same result as the one you mentioned, because it’s impossible for the pixel to be brighter than “1” (which is defined as the maximum brightness).
Until it gets to that final stage, however, anything you do with your color struct (such as multiplying it by 0.5) happens to the unclamped values you provided and can lead to unintended results.
The Color struct in Unity is basically just a data container, and (it seems like) they don’t check for argument validity, so values over 1 are allowed.