If you want glibc, why use Alpine? Mainstream distributions are for glibc. Alpine exists specifically as a musl-based thing.
* ubuntu - Increasingly hostile to container usage (I tried to install a package recently, the install "succeeded" but at runtime the installed binary simply printed 'oh actually this is a stub, use snap instead' and exited), along with all the other downsides of debian (see below)
* debian - Very old packages if you're running a supported version. There's a ton of boilerplate to make apt behave itself in a container environment, something like "apt-get update && DEBIAN_FRONTEND=non-interactive apt-get install --assume-yes --no-install-recommends PACKAGE", compare to "apk --update add PACKAGE".
* distroless - More work to create and manage, can't install things ad-hoc in a running container for debugging purposes
As it is, I use debian and put up with the annoyances and need to occasionally install things from source to get a modern version. But there's really no good options. Alpine would be amazing, except I've hit too many problems with musl (though I'm sure it's not actually musl's fault). If someone was advertising "alpine but with glibc" and it actually WAS that (not "alpine with glibc tacked on top"), I'd use it in a heartbeat.
Was it chromium?
My only guess is that they like Alpine but want to run some binary software that links with glibc.
Among this rather large crowd, Alpine is popular for just one reason: it's small, and dealing with large images is more annoying, everything else being equal. But alpine and, say, ubuntu, aren't always equal. Those people then find one of the ugliest differences, often related to musl, or something they are using relying on glibc-like behavior, and then get to choose between a hack like this, or much larger images.
As an example my organization was moving everything to alpine, but as part of the switch we found out that some computationally heavy tasks were getting significantly worse performance under alpine than with a glibc-based distro, mainly due to the relatively well documented issues with memory allocation performance. It'd not be surprising that someone finding themselves in this kind of situation ends up just adding glibc to alpine, instead of switching back, or figuring out how to tweak the memory allocator.
[side note] I seem to recall there being something about the the way the musl header files are written that basically throws a wrench into any scientific computing code that's compiled with it. Might have something to do with security like those checks intended to prevent people from overlapping memcpy so someone should totally fix that.
There's also gcompat for that, although I don't know how comprehensive that is
Performance in real world applications is worse on musl vs glibc, at a level that can result in higher latencies and needing to spend more on compute resources to serve a given level of load.