This is precisely what happens. The code that configures it is here: certbot/certbot-apache/certbot_apache/_internal/configurator.py at ba9f1939ab54274543f71af0d02eafb2e9be22b3 · certbot/certbot · GitHub
When Apache cannot find an OCSP URI in the certificate, despite being configured to use stapling, it will log these two errors on each start/reload:
[ssl:error] AH02218: ssl_stapling_init_cert: no OCSP URI in certificate and no SSLStaplingForceURL set [<cert details>]
[ssl:error] AH02604: Unable to configure certificate <cert> for stapling
See Apache source code for details (httpd/modules/ssl/ssl_util_stapling.c at 3ce4c8cdf8c42dcc25095186a0c6cf3481cc56dc · apache/httpd · GitHub, httpd/modules/ssl/ssl_engine_init.c at 3ce4c8cdf8c42dcc25095186a0c6cf3481cc56dc · apache/httpd · GitHub).
Apache is known to start even when errors are present, and I have verified that the certificate is still served, though without stapling of course. An apache configtest does not flag this scenario, the error is only detected at runtime.
(As a side note, "the other" popular webserver nginx behaves slightly different: If nginx is configured to use stapling on a cert that doesn't support it, it will print a warning to stdout/stderr during restarts (relatively similar to Apache). However, unlike Apache, nginx does detect this issue during a "config test", i.e., nginx -t flags this)