Why does JVM need to know about time zones?

It's not the VM engine (JIT compiler, etc.) itself, of course. It's a data file that resides in the Java Runtime Environment directory, and some of the standard library code uses this file.

I assume it's done this way because it's the most foolproof way to get consistency across all platforms.

If Java did delegate, it might be hard (or even impossible?) to get the same behavior out of all the different underlying APIs on each platform. And it would be challenging to create the tests to validate that it really does behave consistently.

Also, although it creates extra maintenance work, it has the advantage that it decouples Java-level and OS-level updates. Suppose development machines run one OS (with its TZ data) but QA and production run a different OS. To harmonize environments as closely as possible, it's helpful that you can keep the TZ data versions on all JVMs in sync without relying on multiple OS vendors' patch processes to enable that.

I guess it allows you to implement a JVM that runs on bare metal, or a host without timezone support.

Yep, it makes it easier to port the JRE to platforms like Windows that have an entirely different TZ system. Python, for example, has the same problem. Historically, Python took the stance of providing a "naive" datetime module that provides a conversion API, but delegated the actual TZ conversion to external implementations (dateutil, pytz). Only recently (as of 3.9) have they added a stdlib implementation that uses system-level zoneinfo by default.

Java is not an operating system. Other environments, such as .NET Core, don’t have any issues using the OS timezone database: https://devblogs.microsoft.com/dotnet/cross-platform-time-zo...