.Net (and specifically C#) is one of them, at least for the most things on that list. IF you have the right IDE for it.
Be careful, once you get used to hot reload and moving forward/backwards freely during debug code execution, anything else will feel extremely slow and clunky. I actually write a lot of my C# code in VS first specifically because of that, then just move it to UiPath once I’m content with how it looks (also renames, namespace changes, method and class extractions etc. are way easier and safer there).
Back to the topic 
The core underneath the execution is still based on Workflow Foundation xaml translations, even if it’s a newer port, so I wouldn’t put my hopes up too much for most of the things listed. Effectively a lot of the code gets rewritten whole on any change, unlike “classic” .net that can do diff compiles.
For example, execution can’t move forward and backward because the designer representation that you see is very far from the code that actually gets executed and is just “linked” for debugging purposes.
That said, there could be light in the tunnel for at least a part of it - UiPath already supports persistence and workflow resumptions, so theoretically doing execution snapshots isn’t that far off from that.
For default complex values, I’d suggest something similar to @eyashb but a step further - a helper class for reused test values. For example a public static DataTable GetSampleDt() on a helper class can do wonders for default initializations.
All of that aside, yeah, UiPath Studio is pretty good for an RPA IDE, but if you’re used to Rider, VS and the like, the gaps can get annoying, and it would be great if that could be looked into.