As a workaround, you can always generate a 1px tall, x pixels wide texture to represent a gradient, then pass that to the shader. Then you would sample the texture using the x-co-ord, like you would a gradient.

It's an additional texture sample, which isn't ideal, but it's easy to setup. Wouldn't be difficult to write an editor script to generate a texture out of a Unity gradient either. Then you would just have a collection of them on hand to re-use as desired. You could even organise them in the project like you would other assets.

It can also optionally benefit from mipmaps. So if you have fine bands of color in your gradient that might appear noisy/cause aliasing from a distant, these can be blurred out/softened as the camera gets further from the rendered object. This can be turned of in the textures settings though too.

https://gist.github.com/mattatz/a8c697e212b653ca9ce966797bb93a3c

this kind of destroys the whole purpose of having gradients... you could do extremly smart shaders that are not a hell to maintain

Damn. Why is this property not exposed?

The only way to customize it using exposed properties in shader graph is:

1) use a black/white gradient
2) create n exposed color inputs
2) multiply the sample gradient output with these colors using "mask" to define in with area use the proper color.

This adds complexity to the shader, it was so simply to expose but dunno why they decided to do this.

Well this is a real slap in the face. Is it by design or unavailable by another parts design? I cannot believe that someone "designed" it to not be exposed as it is clearly a gap in the usually user friendly functionality of Unity.
Perhaps the bug is the issue tracker should have another category of resolution as saying this is "by design" must surely be wrong and no better than ignoring Unity's users.