In the sense that in Java (almost) everything is an object, a jOOQ query must of course return an object (such as a Record2<String, String>), but unlike Hibernate or AR, jOOQ doesn't enforce a 1:1 mapping between domain objects and tables, especially if you turn off POJO generation - at my last company, we had some custom mapping from a table to several subclasses of a sealed class depending on certain fields in the table - and you can even split a single class into two tables etc.
> In the sense that in Java (almost) everything is an object,
no, this is misleading. There are different kinds of objects. if you use JDBC to run a query you get back something like a Row object (sorry I havent done JDBC since the 1990s) - the "Row" like object does not declaratively define the fields of the row, the fields and the data of each field are all data. however when you get back POJOs, as you say, these declaratively define the fields that are "mapped" to a column. if jOOQ does this, it's an ORM. ORM has nothing to do with writing SQL - that's called a "SQL builder". the ORM is about marshalling data from POJO-style objects to and from relational database rows.
There are different ways of using jOOQ, some of them being more like an ORM (but still more low-level than Hibernate) and others less so. You can use the API in such a way that it just returns a general tuple object holding the result from your query (called Record1<T>, Record2<T1, T2>, etc.). This is especially useful when fetching from multiple tables. You can also use codegen to auto-create POJOs and mapping code, but this is not required.
"Unlike ORM frameworks, MyBatis does not map Java objects to database tables but Java methods to SQL statements." https://en.wikipedia.org/wiki/MyBatis
"Jdbi is not an ORM. It is a convenience library to make Java database operations simpler and more pleasant to program than raw JDBC." https://jdbi.org/
"While jOOQ is not a full fledged ORM (as in an object graph persistence framework), there is still some convenience available to avoid hand-writing boring SQL for every day CRUD. That's the UpdatableRecord API [which is only one part of it and you don't have to use it]" https://blog.jooq.org/how-to-use-jooqs-updatablerecord-for-c...
ORMs do not require SQL builders. Textual, hand constructed SQL to rows based on tables mapped to objects and you get objects back. "Why don't people learn SQL?" as a retort for ORMs is incorrect.
This is about ActiveRecord, which tries very hard to convince you that a relational database works like objects in memory, especially when it comes to associations, saving etc. Hibernate is similar in that regard (although it at least enforces repositories, but you can still have surprises when it comes to when it loads associated tables). Both allow you to drop down to SQL but then you lose syntax checking / type safety and the conveniences of the library.
With something like jOOQ, the query language is basically SQL, just made type-safe. You write a query that maps to an SQL query 1:1 and then you map the results to whatever you need. No implicit saving, auto-loading of associations in the background etc.
So it's not about "people should use the SQL syntax instead of query builders", it's "people should write relational queries explicitly instead of relying on the framework to save and load stuff from the database when it deems it necessary". Your domain objects do not need to know that they're persisted and they don't need to carry a DB connection around at all times (looking at you, ActiveRecord).
