I feel this is a rabbit-hole we shouldn't venture into.
The slippery-slope argument will make us adding a custom class for each individual user, so css extensions can be used to hide/highlight comments from boss/intern/etc.
It's also probably not enough to remove the hard-coded requirement either - in some environments, one "bot" user is copying comments from another platform, and another is making statistical updates about a jira ticket, so you'd still need a better filter.

I can't see the details in the specific image, but I suspect the bot in question should have their contributions marked differently in the server-side, because they are mostly-useless for everyone. This can probably be achieved by writing a custom transaction rather then adding a comment.

Yessss, I agree and we explored a bit the creation of new transactions as good long-term direction, unfortunately it seems still necessary a bit of CSS help from the backend to cover the legacy data (e.g. 10 years old bot-generated comments, with traditional comments)

the legacy data can be handled by the already-existing hard-coded names...

If you mean this kind of hardcoded CSS rules, yes, it's possible for local installs:

.phui-timeline-major-event a.phui-timeline-image[href="/p/FooBot/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/Stashbot/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/GerritBot/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/Telegram/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/NotARealUser/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/FooBot/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/GitLab/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/Machine/"],
.phui-timeline-major-event a.phui-timeline-image[href="/p/AntonioTheFakeUser/"]
{
    /* do things for bots */
}

I just wonder if maybe we can help our downstream sites, by adding an innocent CSS selector, so this is possible:

.phui-timeline-major-event .phui-system-agent
{
    /* do things for bots */
}

So I wonder if this has sense and it's innocent enough, I would say yes: D25987: Add CSS class to object handle if user object is system agent

Yes, this is where my first comment enters - I feel this is a rabbit-hole we shouldn't venture into, etc.
The current script appears to have 3 names, and referring to "legacy data" implies that there won't be any new names to add.

Personally I'd decline T16052 (data duplication) and I do not yet see a need for potential new transaction types either (a comment is a comment is a comment no matter who/what made it).

However, seeing more and more bot automation (and some of that being automated repetitive notification noise) I believe that adding a generic class to user object handles for bots/system agents (like in T16051 / D25987) will in the long run help human users to find signal between noise.
I have users who'd appreciate visual differentiation between human comments and bot comments when scrolling down comments in a Maniphest task, and that class would create a base for an implementation.
Phorge renders "normal" users vs bots vs mailing lists differently already (e.g. global search typeahead results) and that patch is light. So I don't spot a rabbit hole...yet. :)
You could ofc argue that bots simply shouldn't create comments if some humans consider that noisy but everyone's mileage simply varies, so making it easier for some users to skip bot-created comments sounds reasonable to me.

To put it another way:
I think the described use-case is too narrow, and a naive expansion of the use-case isn't scalable.
The described use-case fails for at least one possible use-case ("some bots have something useful to say").

I can propose 2 alternative solutions:

1. if the bot is generally un-useful, make it create the data as non-comment, and have rendering flexibility on the server side.

We can Introduce a Phorge-level transaction object with metadata that has a similar API to a comment, but is explicitly marked as "not usually useful comment", to make this solution easy on users.

2. If comments made by a specific bot are generally un-useful, we can have server-side option to compact comments based on username. That's low-enough maintenance.

These 2 solve the narrow use-case (server side, for all users).

a comment is a comment...

A comment is transaction-history written in a Comment object if it's something like "this diff was cherry-picked to branch foo by gerrit". I can't see the original example (it's low res), but I suspect that's most of it.
A bot can also be used to port (human-made) comments between 2 systems (e.g., dev jira to client-facing public ticket tracker). These should not be treated like "machine generated" messages.

T16052 is the slippery-slope I was concerned with.

I have not a strong opinion about author usernames (T16052) but if you say to decline that makes sense, especially if at least as small compromise we simplify bot recognition, T16051 and D25987, so that local installs can rewrite their UX without completely nuking their past history and doing complicated comment→transaction migrations on past data.

Thanks for the comments. For context (which I should have included initially), this task was borne out of a conversation between me, @aklapper and @valerio.bozzolan about which parts of a downstream hack I was working on (https://phabricator.wikimedia.org/T393289) could be useful upstream. If the answer is "none", I can live with that.