No, not really.
[...] e.g. SimplexSolver.withSolverOptions(SimplexSolverOptions).
If withSolverOptions is defined in an interface, then SimplexSolverOptions will most probably be an implementation of an interface (say, Options). Options is thus equivalent to OptimizationData: a marker interface (since you indicated that a bunch of options are implementation-specific).
What I did not like about the OptimizationData is that we attempted to create a common interface for things that are different, and that it was not clear which optimizer uses or requires which input.
"Not clear" could refer to a documentation issue, to better highlight required "options" (which is why "OptimizationData" was not named "OptionData").
The purpose was to allow the passing of the same list of options to different optimizers, and each would pick the data it needs. I, at least, had a use for that; but I can agree that it is not a common pattern, especially in strongly typed languages.
you can not use e.g. a BrentOptimizer to solve a linear problem, yet the API allows it [...]
This was a trade-off in order to inherit code which all optimizers need (e.g. the counters). Sometimes multiple inheritance is useful.
If we completely depart from the original design (based on a single hierarchy), many improvements become possible (as with Evan's proposal, and what Luc proposes for ODE, IIUC).
What we should have done [...]
No, we could not have done that; because nobody proposed it.