I don't think anchors' primary function is to allow global definitions (of variables or whatever), rather it's more like arbitrary templates/snippets to be reused through the YAML file.
In GitLab, where YAML anchors have been supported for years, I personally find them very useful —it's the only way of "code" reuse, really. In GitLab there's a special edtor just for .gitlab-ci.yml, which shows the original view and the combined read-only view (with all anchors expanded).
I agree that it's hard to point to the specific line of the source code, but it's enough — in case of an error — to output an action name, action property name, and actual property value that caused an error. Based on these three things, a developer can easily find the correct line.
In my experience include/extends works well for importing or extending whole jobs, but not so much for defining a small snippet of text that I want to reuse across many jobs, perhaps when overriding stuff.
An example of how I normally use them and why I still find them useful:
# Imports whole pipeline architecture jobs
include:
- project: company/ci-templates
ref: "master"
file: "languages/stack.yaml"
# Define a command I need to use exactly the same
# across different jobs I'm going to override
.vpn_connect: &vpn_connect
- cmd1
- cmd2
- cmd3 &
job1:
extends: imported1
script:
- ....
- *vpn_connect # 2nd command
- ...
job2:
extends: imported2
script:
- ...
- ...
- *vpn_connect # 3rd command
- ...
In GitLab, where YAML anchors have been supported for years, I personally find them very useful —it's the only way of "code" reuse, really. In GitLab there's a special edtor just for .gitlab-ci.yml, which shows the original view and the combined read-only view (with all anchors expanded).
I agree that it's hard to point to the specific line of the source code, but it's enough — in case of an error — to output an action name, action property name, and actual property value that caused an error. Based on these three things, a developer can easily find the correct line.