No. Absolutely not. This is the fundamental mess that ORMS create.
Objects DO NOT map cleanly to tables.
Eventually your code discovers this, and suddenly it's a world of pain because the ORM can't handle it.
Let me tell you one thing that isn't solved yet: Serialization of arbitrary objects to json and back.
How do you deal with two refererences pointing to the same object? Duplicate the data?
What about circular references? Give each object an id and save a symbolic reference?
What about polymorphism? Should a json array be turned into an array or an list or a json map turned into an object or a hashmap?
You need a type discriminator attribute.
ORMs have already solved those problems well.
The actual problem is that databases are distributed systems and you still have to write queries with the still 10 times better querybuilder of your ORM. Just try writing raw JDBC queries. It's so painful I'd still use the ORM even if my project only uses native SQL queries via the ORM api.
You will probably now ask what's the point of ORMs if you still have to write queries? Well, it's in the damn name. Object relational mapper. It maps stuff. It's not advertised as WYQFY. "Writes your queries for you"
As mentioned, if you're in the 1% scenario where this approach doesn't work then you already know you should be using something else. Not knowing when to use what is a far bigger issue than any problem an ORM can cause.
If you throw away the concept that anything in your database has to map to anything in your code base, then you design better databases. Different databases, more to the point.
You can lay out your tables however you want, and you can then map them to objects using an ORM. That's what mapping means, to translate from domain to another. There's no limit on how things are actually designed and ORMs usually do a much better job of handling all that bulk code for you. Nothing is stop you from writing SQL yourself if you really need something complex but again, you should know when and where that is.
What? Definitely the opposite. First of all, ORMs are just tools, as the name implies they are object-relational-mappers. That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one.
Modern ORM frameworks are incredibly more productive with better security and reliability than hand-crafted SQL and mapping code. Unless you're working at serious scale, doing custom reporting, or other complex scenarios, they handle 99% of CRUD database operations perfectly well. Wasting time reimplementing an existing tool is quite literally throwing money out the window.