The specifics of how the database connects to the application layer are abstracted away from us. In Java, a generic interface had to be provided to allow access to the database, which means that even though there's a handful of classes for interacting with databases, it involves things like selecting drivers, writing database-specific SQL statements, and so on. This is because Java was meant to run on a variety of hardware and software, to allow maximum portability.
In Apex Code, the language was purpose built to translate our queries into just one specific underlying SQL syntax (Oracle SQL, in this case), using just one driver, and so on. We're not forced to learn Oracle SQL, nor do we have to learn how the drivers operate, etc. We're given all the tools we need so we can focus on writing business logic, not learning the specifics of the underlying platform.
You'll notice how we also have similar constructs elsewhere. There's one standard interface for sending emails, one for calling REST services, one for call SOAP services, and so on. Instead of working with sockets or streams, we're given a simple "go to this URL and give me the results" API. Instead of writing POP3 or SMTP messages, we can handle incoming and outgoing email requests using just a handful of objects.
In other words, we don't need to know, because we have a team of developers and engineers that are constantly monitoring the database and tweaking the system to deliver the best performance, without us having to select drivers or driver options, heavily focus on optimizing Oracle SQL calls, and so on. Our purpose is to build applications that serves our business' needs instead of catering to the platform's tuning and maintenance.