Agree, but you’ll quickly discover that trying to fully automate this will be fraught with problems and ultimately fail to achieve its main objective.
For example:
You could extract the curves from each Family then find the curve at the tip of the fin closest to the grid line, then work out the angle of rotation…and deal with the fact its curved…but not before getting the centre point of the Family (this wont always be possible depending on the geometry in the Family)! The only way I know to get curves from say, a Detail Family, is via the API and that’s before you’ve even started to solve the problem. Also, you would need to create a set of rules to handle the + or - rotation that will result from the family position relative to its fin closest to the grid line.
It gets worse: even if you did get it working, this approach would only work with this family and no other since you are looking for a curve specific to the makeup of this Family. The amount of time you’ll spend doing this will be grossly disproportional to the length of time that single manual intervention at the start would provide, which is why its the most sensible approach with this kind of problem. In addition a hybrid approach would ensure the solution would work on any Family type as you wont need to concern yourself with finding a specific piece of geometry to get the whole thing functional. Maintenance also becomes a lot more easier and manageable. If you work in a team, this is a key consideration. A single-use solution with any script is never worth it.
What I would say is that with any process, particularly where computation is concerned, its critical to establish what should be automated and what shouldn’t.