Assuming ssl_stapling_verify is on, yes. Otherwise it passes it through unchecked.
I would advise @wbounni against turning off stapling verification though (as that makes the stapling prone to caching bogus responses as well) and ask what use case is being solved here.
X.509 certificate revocation is broken. The technology has fundamental issues - certificates not being seen as revoked when they are is very common. Many implementations do not check for online revocation at all (e.g. Chrome does not talk to OCSP servers, nor does it fetch CRLs live). Therefore, what you're seeing is often expected: A server will typically not send a "bad" (i.e. revoked) stapled OCSP response (why should it? That would just break the connection) and an increasing number of clients won't bother doing OCSP themselves.
Firefox is one of the browsers that offers a live OCSP query, but it's a best-effort implementation that is cached, so you won't always see revoked certificates immediatly. This feature is also disabled by default IIRC.
Browsers are currently implementing some sort of stopgap by making CRLs popular again (A New Life for Certificate Revocation Lists - Let's Encrypt, Firefox CRLite + Chrome CRLSets). However, for the long term future we will likely push towards very short certificate lifetimes which gives us passive revocation (Good certificates die young: what's passive revocation and how is it implemented?).
I would generally advise to never rely on working certificate revocation for anything. It's nice to have the option to revoke certificates, but it is far from being a reliable method.