Tests and CI help you make sure that functionality actually works, that buttons you press have the desired effect, and that if I as a contributor ship you a pull request for a UX/feature improvement, both your and me can check that it doesn't break anything before merging.

The grandparent poster also wrote about security/privacy, for which I think tests are pretty important.

Finally, having CI would allow the developers/contributors with limited time to spend more time on usability and usefulness instead of on issues like "master doesn't build, anybody else have this problem?" (when I wanted to PR something to Signal, master did not build).

This is still looking at it from a developer's or contributor's point of view. Developer velocity has no practical impact on the user experience. In a way, the constant addition of features or tweaks to the user experience is a net negative, since the user has to re-learn how to do things in the app.

This also makes the assumption that since there are few automated tests, that there are no tests done on a build at all. I disagree that it is a valid assumption. Most security vulnerabilities are not found by unit or functional tests, but instead by linting and code reviews.

> Developer velocity has no practical impact on the user experience.

This may be true in a megacorp. I doubt it's true in a project like Signal where resources are limited and a few developers are the single bottleneck for everything, UX or otherwise.