This wouldn't prevent an attacker from using the actual app to generate an attestation and then reuse the received JWT elsewhere; that's probably fine. If not, for a more heavy-handed approach, OAuth has a Demonstrating Proof of Possession extension that lets requests be signed with a key that's agreed upon when the access token is received, but which is kept secret by the app. There's also a draft spec for applying this to mobile attestations specifically.

We need to be careful not to block Android users who don't use Google Play.
Devices sold in mainland China and Huawei smartphones sold worldwide lack Google Mobile Services due to local regulations and sanctions: https://arstechnica.com/gadgets/2019/09/huaweis-new-flagship-smartphone-ships-without-google-apps/. I’m not sure whether this policy is still in force today, but it certainly applies to all Huawei phones sold at that time.
New sanctions such as this can arise as a result of geopolitical events, which have been far from calm these days.
Also, some phones are sold in Europe with Android forks like https://en.wikipedia.org/wiki//e/_(operating_system) or https://en.wikipedia.org/wiki/IodéOS, that may not support Play Integrity API.
I also remember having a bit of a struggle with FireOS, Amazon’s Android fork, because of Google Integrity issues that were preventing me from accessing certain apps.

According to Fdroid documentation:

The implementation of proprietary tracking or advertising libraries and analytics tools such as Google Play Services and Firebase and Crashlytics and proprietary ad/tracking SDKs are strictly forbidden in all applications.

Assuming Play Integrity API falls in this category, we will therefore need to maintain a separate opensource-only build version that doesn't contain this external library, so that Wikipedia can remain on F-Droid. (But perhaps it was already done with rAPAW09ee936d052f0872a54ecf5249ce5e6e95db3fc2 ?)

In T431910#12111762, @Framawiki wrote:

We need to be careful not to block Android users who don't use Google Play.

That's a valid concern, but in a situation where e.g. someone does a DDoS attack while forging the Wikimedia app fingerprint, we might have to chose between blocking all apps vs. only those that cannot use platform attestation. (Browser fingerprints can also be forged of course; what makes the apps special is that rolling out new code to them takes a long time, so we cannot do ad-hoc client-side mitigations.)

I don't have a good sense of how likely and how impactful such a risk is, or how much effort this would be on the app side. MediaWiki-Core-Platform-Team can work on the MediaWiki side of this if it's deemed important, but the prioritization decision would have to come from somewhere else.

(One thing that came up while discussing this: would this be a form of unique tracking for potentially anonymous users? I think the answer is no, but I only skimmed the docs, so that's something to look into if we pick this up.)