You mention that it's much omre laborious to write a struct that matches your data exactly - however, I've found that, at this stage in the process you already have some sort of schema (mental or formal) of what your data is, and it's fairly trivial to write out a structured representation of it.
What this then buys you is a semantic understanding, in your code, of what 'bad data' is and how it's handled. You know that if you get a string where you expected an int, that's a problem. You also know that if data is missing, eg: null, that you'll handle it.
In Python, a function can erroneously return None. To your data, this is just a missing value, not a bug. But there is a semantic difference, and a cost associated with that bug.
All of these problems, limited strictly to working with data, are far easier to react to and deal with in a static language.
We absolutely conceded the exploratory phase to Python. It is, and will likely remain, an excellent and near-ideal tool for that phase.