FWIW, we start to use tags for our own test suite (e.g. run some checks on sampler supporting Dask array and dataframe).
But it is also limited currently because scikit-learn does not have a stable API on the testing framework (cf. #18750) which might be a little refraining as a usecase for most third-party libraries.

#18797 is indeed making the use of tag optional. However, it should be noticed that, currently, tags are enforced by using BaseEstimator. But BaseEstimator is indeed doing more than enforcing tag. My point is that if we go toward enforcing tag, we might want to have a specific Mixin which should provide only tag functionality?

Are there any other reasons for third party developers to adopt tags?

None that I can think of. I think you summarized the main points well. But we can also ask for feedback from maintainers of scikit-learn compatible projects, to get a better idea of how they feel about tags.

Are there any other reasons for third party developers to adopt tags?

Actually an issue where a developer of a third-package wanted to use tags programmatically in their own estimator. It might be difficult to find the comment through our issue tracker.

Last year when I was working on a training on "how to write your own estimator" on a language usecase, since the input wasn't a numerical ndarray, and rather a list of strings, I had to use tags to pass check_estimator. To me for all those usecases using tags is a must for third party developers, and I see no reason why we shouldn't make them use it.

Update: Tags are not a part of the public API via __sklearn_tags__, and they're used in sklearn.utils.validation.validate_data, which is also now the recommended way to validate input.

So I'd say we can move ahead with requiring tags.