if crash reporting is opt-in (i.e. disabled by default but it can be enabled in the app settings) the app is acceptable for their policies because users have to give their consent to enable reports (which are a form of tracking).
I guess F-Droid's logic makes sense.
Q:
What exactly Sentry collects? What kind of identifiable info goes out of the phone?
The stacktrace of the exception, operative systm version and app version, the date when the crash happened (as well as statistics on the number of occurences over time), device manufaturer and model, whether the device is rooted, the system locale, whether the app is in background, battery level, orientation when the crash occurred. It could collect other data that classify as sensitive information (e.g. IP addresses which may give hint about the location) but these can be disabled.
It's not me, the developer, who can use this data for profit (which is quite obvious since I am a volunteer): what is really at stake here is whether it's worth putting these data in the hands of a corporation (this is not a self-hosted service, I would be running on their servers and using the free plan)... It's a cost-benefit tradeoff, plus the setup which is not exactly trivial, especially since I have to change the release pipelines for CI/CD because the build breaks.
If Raccoon ever crash on me, I'll copy the logs that are saved on the phone in app data folder... I wouldn't use Sentry (TMI), but others might like the convince...