Not much really... In many languages ORM's require just about as much boiler plate or careful error checking as copy pasting SQL strings with supportive structs... Not saying ORM's are bad, some are OK some are maybe even good. Project/team dependent...
That said, I find the concept of abstracting ML ingredients outside of languages a nice one although its not entirely novel(python's been doing this from day 1 :D). The strength for keeping it in 1 language can be profound though. Compilers can optimize across operations. Calling many atomic functions from an API/server from a client loses that unless implemented carefully. That one language benefit is a big part of what Julia has to offer.
I could see a value addition statement being made if the "whole market" solution included a lot of goodies. But every time I think of what that looks like - I think it looks like Julia in 2-5 years....
Boilerplate. Writing serializers and deserializers by hand is not an efficient use of developer time.
Related to ORMs, but not quite on topic - query building. Type checked queries, parts of which can be passed around business logic, are very powerful and flexible.
There are more and more libraries that let you to write SQL and bind the results into native records (objects, structs) in the host language. I find it an interesting middle ground
But what actual problem is ORM solving beyond that?