Possible the biggest major advantage that a speedrunning mod would offer over using external tools would be the ability to automatically start/stop/split based on in-game events.
Starting, and dealing with pauses (i.e. keeping an RTA timer "ticking" across SP pausing) is not terribly difficult; both Piranesi Restoration and Citadel have examples of that.
Splitting and stopping the timer is much harder, because you'll probably need at least some degree of game-specific logic for it. Right now each game only has "final goal" logic, and in each case it's tied to something very deeply entangled in the game. This means to be game-generic, you'd need to either implement a lua editor, or a "plugin" type system (e.g. compatibility mods linking the general-purpose speedrun mod to each specific game).
Mid-run intermediate goal definitions
Currently neither Piranesi nor Citadel have mid-run splits; in part I did this because I wanted to write a single timer mod that's universal for all routes and categories, and splits would have to be route-specific. However, if you had a configuration system for separate routes/categories, you could probably build split detection around a handful of simple in-game primitives.
I don't know how well it would work with other game types (e.g. survival) but detecting items in inventory would actually be a pretty robust way to define intermediate goals. For Piranesi and Citadel, the main objectives are key items. For something like NodeCore or MTG, searching for items in specific slots, or a certain total quantity in inventory of certain items, could cover a lot of cases.
Reaching certain x,y,z locations (or passing through certain planes, or inside/outside a certain radius) could also work as goals, especially for parkour-based games like Velvet Crystal, though you have to be careful about globalstep precision (though coarse steps could already be a problem for speedrunning in general anyway).
Given these options, it may be possible to auto-split based on configurable in-game cues that don't require sandboxing general purpose code.
Further background from visual autosplitting
For some further background: for my blindfolded NES speedruns, all of my splitting is automatic, and it's all based on video capture using image compare against certain regions of the screen; things like inventory and location splits are possible this way by looking for visual indicators like scenery or HUDs, as long as camera angle is stable (which needs to be the case for blindfolded, but for visual runs, you may not be able to look for exact camera angles or positions).
I compromise the locations where I put my splits based on what's technically possible. Especially for Luanti games, there tend not to be established runs, so splits just need to be separated by an appropriate amount of time such that each one only contains one major "risk" so that being ahead/behind on the split tells me which difficult part was likely the culprit.
One thing that my visual splitter needs to handle is a certain degree of state machine functionality, i.e. some things I detect when a signal is raised and in other cases, when the signal is lowered again. I try to avoid making complicated state machines for my splits (since the image compare algorithm is expensive) but both rising edge and falling edge triggers at least turned out to be necessary.
Possible the biggest major advantage that a speedrunning mod would offer over using external tools would be the ability to automatically start/stop/split based on in-game events.
Starting, and dealing with pauses (i.e. keeping an RTA timer "ticking" across SP pausing) is not terribly difficult; both Piranesi Restoration and Citadel have examples of that.
Splitting and stopping the timer is much harder, because you'll probably need at least some degree of game-specific logic for it. Right now each game only has "final goal" logic, and in each case it's tied to something very deeply entangled in the game. This means to be game-generic, you'd need to either implement a lua editor, or a "plugin" type system (e.g. compatibility mods linking the general-purpose speedrun mod to each specific game).
Mid-run intermediate goal definitions
Currently neither Piranesi nor Citadel have mid-run splits; in part I did this because I wanted to write a single timer mod that's universal for all routes and categories, and splits would have to be route-specific. However, if you had a configuration system for separate routes/categories, you could probably build split detection around a handful of simple in-game primitives.
I don't know how well it would work with other game types (e.g. survival) but detecting items in inventory would actually be a pretty robust way to define intermediate goals. For Piranesi and Citadel, the main objectives are key items. For something like NodeCore or MTG, searching for items in specific slots, or a certain total quantity in inventory of certain items, could cover a lot of cases.
Reaching certain x,y,z locations (or passing through certain planes, or inside/outside a certain radius) could also work as goals, especially for parkour-based games like Velvet Crystal, though you have to be careful about globalstep precision (though coarse steps could already be a problem for speedrunning in general anyway).
Given these options, it may be possible to auto-split based on configurable in-game cues that don't require sandboxing general purpose code.
Further background from visual autosplitting
For some further background: for my blindfolded NES speedruns, all of my splitting is automatic, and it's all based on video capture using image compare against certain regions of the screen; things like inventory and location splits are possible this way by looking for visual indicators like scenery or HUDs, as long as camera angle is stable (which needs to be the case for blindfolded, but for visual runs, you may not be able to look for exact camera angles or positions).
I compromise the locations where I put my splits based on what's technically possible. Especially for Luanti games, there tend not to be established runs, so splits just need to be separated by an appropriate amount of time such that each one only contains one major "risk" so that being ahead/behind on the split tells me which difficult part was likely the culprit.
One thing that my visual splitter needs to handle is a certain degree of state machine functionality, i.e. some things I detect when a signal is raised and in other cases, when the signal is lowered again. I try to avoid making complicated state machines for my splits (since the image compare algorithm is expensive) but both rising edge and falling edge triggers at least turned out to be necessary.