I agree it’s scattered, but in practice those bits and pieces are well battle-tested, so it becomes hard to rationalize a thin wrapper around them just for convenience’s sake (when you can be production ready with a handful of function calls, or defdelegates if you want to make your own holistic interface).
Not saying we shouldn’t make a nice convenient wrapper—see, for example, the widely popular ets package—just encouraging you to articulate where you could see such a library substantially adding value, enough to rationalize a new dependency.
That kind of shopping list is what motivates people to strike dirt and create a new library. 
I myself have thought about it before, for example, but ultimately the only two compelling differentiating features I’ve been able to come up with would be an Ecto.Type and streamlining SOAP handling specifically, both of which work just fine as their own stand-alone libraries and do not benefit substantially from being tightly integrated with the other bits and pieces of validation, streaming, building, etc.
The other attractive proposition for a holistic wrapper library would be to improve upon the Elixir ergonomics of working with the erlang libraries’ records. However, since polymorphism isn’t particularly useful in this domain outside of tapping into existing protocols—specifically Inspect and Enumerable—I’ve found that motivation to be sufficiently lacking to build out a library for that purpose alone.
One day something may tip that scale, and conversations like these are what cause me to mix new in my ~/code/oss/elixir folder more than anything.
