The real problem is that there's something like a dozen different ways to import/export data and all of them do something
just a little bit different, even when their accessed via pretty much the same interface. Datapump didn't work because there was a minor version mismatch between two of the dBs, something like a single letter in the version. We weren't using any features at all that distinguished our use of one dB over the other, so the data should have migrated smoothly.
SQLLDR threw up a bunch of index and constraint errors that magically went away when we just copy pasted in the INSERT statements into the GUI tool. Why? Who knows, but we didn't want to spend another $400/hr figuring it out.
CLOBs shouldn't be some magical type that's impossible to serialize and deserialize. There's nothing particularly tricky about serialized text in almost any other technology context, except in magical Oracle-land where all the tools are broken and you can measure how many dollars each row of data is costing you.
We weren't doing anything particularly exotic, or sexy, just very very vanilla relational dB 101 stuff, and Oracle has managed to turn that into expert-level wizard secrets. It doesn't matter how Oracle internally works, if we have to know, especially for these kinds of simple use-cases. If you have to know, you may as well just write what you need yourself instead of relying on a tool.
I agree with stickfigure, defenses of this garbage end up becoming an indictment of it.