Other locale aware functions also do not respect the set locale in Apache such as:
printf("%.2f\n", 1000000.123);
which outputs 1000000.12 in Apache and 1000000,12 in the CLI (after setting locale   succesfully to nl_NL.utf8

According to the bug report in the link below, it seems that mod_perl is the culprit and that is what I have installed too:
https://bugs.mageia.org/show_bug.cgi?id=25411

I wasn't able to reproduce the bug on a few other Debian 10.11 machines that I tested that did not have mod_perl installed, so I assume that that is the case.

Hopefully a fix/workaround can be created, or at least a note about this conflict with mod_perl can be added to the documentation.

> Hopefully a fix/workaround can be created, or at least a note about this
> conflict with mod_perl can be added to the documentation.

Note that there is already a warning about using setlocale() in a multithreaded environment.
> Warning
> The locale information is maintained per process, not per thread. If you are
> running PHP on a multithreaded server API , you may experience sudden changes
> in locale settings while a script is running, though the script itself never
> called setlocale(). This happens due to other scripts running in different
> threads of the same process at the same time, changing the process-wide locale
> using setlocale(). On Windows, locale information is maintained per thread as
> of PHP 7.0.5.

Whatever mod_perl is doing, it's in the same process and it's also screwing around with the locale.

No idea what the specific interaction with mod_perl here is, but the general "workaround" for this issue is to stop using locales.

PHP 8.1 deprecates strftime() to encourage migration towards alternatives that are not locale-based.

I don't think it is enough to blame mod_perl2.

The last working setup in my case was
Apache 2.4.29 and mod_perl2 2.0.10, mod_php7.2 7.2.24
Now, on
Apache 2.4.41 and mod_perl2 2.0.11, mod_php7.4 7.4.3
it does not work anymore.

The bug report here states it does not work with php7.3, either.
mod_perl2 has only changed its version in the patch level.

I took a look at the changelog of mod_perl2 (which is not excessively large ;-) ):

=item 2.0.11 October 5, 2019

Fix t/modules/apache_resource.t failures [Steve Hay]

Fix [CVE-2011-2767] Arbitrary Perl code execution in the context of the user
account via a user-owned .htaccess. Patch from bugs.debian.org #644169. [Jan
Ingvoldstad <jani+debian-2011+@ifi.uio.no>]

Fix potential test suite hangs due to pipelined response deadlocks. Patch
from rt.cpan.org #82409. [Zefram <zefram@fysh.org>]

Fix t/compat/request.t failures [Steve Hay]

Fix use-after-free segfault in ap_server_config_defines seen on start-up on
OpenBSD. [Found/fixed by Sam Vaughan/Joe Orton]

Fix build with Perls earlier than 5.13.6. [Rainer Jung
<rainer.jung@kippdata.de>]

Fix filter/in_bbs_inject_header.t test failure with Apache 2.4.25+. [Stefan
Fritsch <sf@sfritsch.de>]

Fix apache/read.t test failure with Apache 2.4.25+. [Niko Tyni
<ntyni@debian.org>]

I also took a look at the exact diff of every file between the two versions at https://fossies.org/diffs/mod_perl/2.0.10_vs_2.0.11/

and the changes are so minor and/or irrelevant that I cannot imagine that a *change* in mod_perl2 can be the cause.

That is to say there could be some change in mod_php >7.2 that introduced the incompatibility. Which might be necessary, I am not trying to blame anyone or any product here!

I am not an active developer. I am just trying to inquire whether it might be possible to find a way of making php>7.2 work nicely with mod_perl2 as well. It has been working for years, after all. Just stating "there may be problems, so don't use it" feels like the easy way out. I guess there have been lots of Apaches out there serving perl and php happily in parallel.

Or maybe the problem lies within apache itself?
I can't say.

Sorry, our comments overlapped.

I am only seeing this with nextcloud, all other PHP services I have tested until now work as they should, even with mod_perl2 enabled.

I'll try to figure out whether this is a known issue of nextcloud.
Do you mean that setting locales is generally discouraged, i.e. not only when using strftime()?

On a sidenote (also for those fighting with nextcloud):

If I uncomment
. /etc/default/locale
in /etc/apache2/envvars
and therefore let Apache apply the default system locales, nextcloud is happy, presumably because setlocale() did not work as well, but still the set locale is correct/not "C"/one of those expected by nextcloud (as it got pushed into the environment upon the web server's start).

This is in no means a fix for setlocale() not working but might be more in line with nikic's advice to stop using setlocale() altogether (and - at least that's how I interpret it - set the locale in a different, more global/reliable way).

Maybe this should be part of the documentation?
I don't quite understand why Apache on Debian does not use the system's default locale as its default as well, though, but maybe I don't have to :-)