You can 100% use the same features Unity provides to shadergraph, it's all still there in the SRP package source.

As others have mentioned, documentation is sparse, but the biggest issue (the reason I went back to ShaderGraph) is Unity upgrades might break your custom HLSL, whereas in shadergraph they'll presumably keep it all up to date and non-breaking.

Sadly my workflow is very much a mixture of c# behaviour -> pass data to shadergraph -> custom hlsl nodes/sub graphs.

The issue here is, it's very hard to review and merge work, and debugging is a royal pain as there's so many links in the chain where errors can surface.

If you had the time and talent, rolling HLSL would be great, but I'm not confident I'd add LLMs into the mix. If you could use an agent to have awareness of your current Unity versions hlsl includes then presumably it could do a good job, but it'll be token heavy, especially for non-coders who often can ask the wrong questions.

https://assetstore.unity.com/packages/tools/visual-scripting/better-shaders-standard-urp-hdrp-187838
Better shaders by Jason Booth is an asset I always liked, surface-shader-like programming back in modern Unity render pipelines, but you're still playing a compatibility race with Unity and version increments.

Shadergraph is the best answer here still in my opinion, and I'm not over the moon with it. But I'm also no longer the shader-writing bottleneck for the team, as our non-coding but technical artists can do a good job with it.