Disclaimer: I have never worked with SQL triggers.
SQL triggers need additional software / SQL developers in the IT department. In my organization, server management software is not available for non-IT staff. So I would have to coordinate with IT staff to get what I want. AFAIK, nobody in our IT department knows enough about SQL to write the triggers. I need lots of automatic edits in my database, and during development, my requirements frequently change. In that case it's much easier to learn about Arcade and implement Attribute Rules myself than wait forever for IT to find the time.
With Attribute Rules, you can view, create, and edit the data structures, triggers, and data in the same application.
You can use Arcade to do other stuff (e.g. popups, labels, visualization, dashboards), so it's actually quite useful to learn.
With SQL triggers, you lose all geodatabase functionality. Things like Editor Tracking, Versioning, Archiving are all done automatically with Attribute Rules, while you have to implement that yourself with SQL Triggers. For example, if you edit a versioned table with SQL Triggers and want to emulate the versioning, you have to edit at least the two delta tables, maybe also some geodatabase system tables.
Attribute Rules tell you when something is wrong. If you made obvious errors, it won't even let you save the Rule. If you made less obvious errors that only emerge at runtime, you get an error message telling you where the error occured, which is of course extremely helpful for development. I don't know if that is the case with SQL Triggers.
Constraint Attribute Rules are a helpful tool. For example, you can reject edits that change a value to be out of some arbitrary bounds, or you can reject edits if the geometry falls inside/outside of a specific area. You can probably do something like that with SQL Triggers, too, but with Constraint Attribute Rules you can define a custom error message to tell the user what is wrong.
Validation Attribute Rules let you define some rules that are checked on demand, so that you can do manual quality assurance.
Deprecation: Of course this is always a possibility. But Arcade is a new feature that is under constant development and is meant as a language for the whole ArcGIS environment, so I doubt it is going away any time soon. Attribute Rules are a feature of the Geodatabase, whereas Python addons were a feature of the application, that probably also makes a (favorable) difference in regard to deprecation.
Locking: Yes, that can suck. In my case, I have only one coworker with write access, all others have only read access. And they don't see (and therefore don't lock) the actual tables, but database views. Another way is to disallow connections as geodatabase admin and then ask the database/server admin to close all existing connections.
Limited functionality: I think all the basic stuff is there, and they add new functionality quite frequently. Of course, it isn't as extensive as older languages (and probably never will, as it's developed for very specific purposes).
Performance: Rules that only affect the edited feature are quite fast. If you do huge chunks of edits at once, you will notice it. If you do single manual edits, probably not. More complex rules (filter tables, intersection, edit other tables) have a higher performance impact. Manual edits on some of my feature classes can take up to 3 seconds to evaluate the rules. But they are filtering 2-4 tables, do at least multiple intersections and send edit requests to multiple tables that trigger rules on those tables.
Accessing vertices: Polylines and Polygons are modelled as array of arrays of points (multipart features). You can access vertices like this:
// polyline
var geo = Geometry($feature)
var multipart_path = geo.paths // [ [Point] ]
var singlepart_path = geo.paths[0] // [Point]
// polygon
var geo = Geometry($feature)
var multipart_path = geo.rings // [ [Point] ]
var singlepart_path = geo.rings[0] // [Point]
for(var i in singlepart_path) {
var p = singlepart_path[i]
Console(p.X + "/" + p.Y)
}
All in all, I'm a big fan of Attribute Rules and Arcade. It has enabled me to do stuff that I couldn't do with Attribute Assistant and Python Addins. My IT department would hate me if I would come to them asking to change SQL triggers all the time, and I can use the Arcade knowledge I gained to create good-looking popups and do some light label and symbol customization. If you don't do constant automated edits of huge chunks of data, I'd go for Attribute Rules.
Have a great day!
Johannes
