You should be concerned when an engine says that it does support text-based shaders, because such a feature will limit you to a single platform, and it will not provide a clean separation between lighting/fog properties and material properties. Think about it -- suppose you make a custom material shader for some kind of object in a text-based shading language like Cg or HLSL. Now, what types of light source do you want it to work with? Point lights, spot lights, infinite lights, lights with projected texture maps, lights with shadow maps? You'll need a separate version of your shader for each one of those. And what about fog? If you want your custom material to work in different fog environments, you'll need to write additional versions of your shader to handle that, multiplied by the number of light sources. With the current number of light types and fog types supported by the engine, you'd be writing 24 variants of your custom shader just to ensure that your material works correctly in all possible environments. Do you see the problem here? And then what happens if a new light type is added to a future version of the engine (and they will be)? All of a sudden, there are cases in which your custom shader doesn't work at all. Better go back and write a few more variants for every shader that you've already written.
.
.
.
The nice thing is that the engine still generates the final shader code on the fly and adds the appropriate lighting and fog code automatically. Because you don't use text-based code, shaders created with the shader graph editor are still future-proof -- they'll continue to work when new light types are added to the engine, or even if the underlying shading language is completely replaced. Furthermore, shaders created this way will work on the PC, Mac, and Playstation 3 without you having to lift a finger to port from one platform to another.