This would be an internal refactor; I don't think the user would notice any changes (at least not at first). The advantage for the user would be that this would more lightly wrap the Keras API; a lot of the code in #88's _validate_data could be removed. In #88, _validate_data does the following:

1. Runs Scikit-learn's check_X_y
2. Casts to appropriate dtype.
3. Checks X/y shape
4. Checks the number of features in X.

I think (3) and (4) could be moved to checking the Keras input (after the user input has been run through the target/feature transformers). I think (2) can be enhanced with closer integration to the Keras model; there might be better error messages with np.can_cast(X.dtype, self.model_.layers[0].dtype).

I am just now seeing this last comment. This sounds interesting, I am +1 on anything that reduces code complexity.

That said, I think this would be a fundamental departure from how Scikit-Learn does these validations? _validate_data is meant to validate that data passed after the first fit/initialization matches what the estimator knows. I'm guessing sklearn does it like this mainly to avoid cryptic failures within estimators, but like you say we may be able to check the "source of truth" (i.e. the Keras model) to achieve the same effect. Got to think about it a bit or see it implemented.