In SpecialWatchlist, tags are parsed via ChangesListSpecialPage::getChangeTagList
In ApiQueryWatchlist, info is retrieved from WatchedItemQueryService::getWatchedItemsWithRecentChangeInfo, and tags are processed with:

if ( in_array( self::INCLUDE_TAGS, $options['includeFields'] ) ) {
	// prefixed with rc_ to include the field in getRecentChangeFieldsFromRow
	$fields['rc_tags'] = ChangeTags::makeTagSummarySubquery( 'recentchanges' );
}

this rc_tags value should not be changed, since it should still be possible to get the unparsed tags associated with edits. I would suggest parsing the tags within the API.

Yes, some older endpoints do provide UI HTML. We're trying to move away from that.

@Anomie - I'm not sure I understand the reasoning here. Can you walk me through it? It seems to me like the vast majority of use cases for the API would prefer HTML over Wikitext, especially for things like comments and tags. Since we don't have a client-side parser, that means forcing them to do another round trip. Why do we want to do that?

In general in MediaWiki over the past few years we've been trying to move towards separation of concerns. Separating fetching of structured data from generation of UI HTML is one of those separations.

Producing HTML brings dependency on the parser, and on the current user's preferences. It also potentially brings a need for additional parameters to control parser options, and can result in bugs like T247661.

It seems to me like the vast majority of use cases for the API would prefer HTML over Wikitext,

That seems like a hard one to estimate. How much of the use of the API is for UI-generating gadgets and apps, versus bots and data access and scripts that add functionality rather than UI? My own guesstimate would be that bots (including various scrapers that never log in) make up the vast majority of Action API requests.

Since we don't have a client-side parser

mediawiki.jqueryMsg seems like it would probably suffice for turning the tag name messages' wikitext into HTML as requested here.

Producing HTML brings dependency on the parser, and on the current user's preferences. It also potentially brings a need for additional parameters to control parser options, and can result in bugs like T247661.

Thanks for that break down. I now understand much better why we're moving away from supplying parsed results.

That seems like a hard one to estimate. How much of the use of the API is for UI-generating gadgets and apps, versus bots and data access and scripts that add functionality rather than UI? My own guesstimate would be that bots (including various scrapers that never log in) make up the vast majority of Action API requests.

In my mind, things like HTML links and transcluded templates are more content than UI. I think it makes sense to have separation of concerns, but maybe we have different opinions on where the line of separation should lie. Regardless, it sounds like it would be tricky to fix this without causing other problems.

mediawiki.jqueryMsg seems like it would probably suffice for turning the tag name messages' wikitext into HTML as requested here.

That's true, and probably true for some other use cases as well. I'll see if I can help push things in that direction. Thanks.