While looking at the code for this again, I saw a couple problems, which I verified through the debugger.
The former behavior used to support 2 formats: "lat,lon" and WKT, and it did this very efficiently – it could tell it's WKT immediately and if not it parsed using SpatialUtils.parsePointSolrException (the lat,lon format).
Now, it'll use the Spatial4j shapeReader configured, which if not configured (true for existing configs and I suspect for the majority of folks going forward still?) it'll be arbitrarily the first one. By coincidence that's GeoJSON. No matter what it is, however, parseShape will try all ShapeReaders in Spatial4j registered with the SpatialContext. This even includes, sadly, LegacyShapeReader which parses "lat,lon" and some stuff like "Circle(x y d=dist)" that we stopped supporting many releases ago. Some of these readIfSupported impls throw exceptions to signal they don't support it. So in summary, (1) this is slow, and (2) IMO if you configure= format X then we should only parse as format X. I have reservations about the notion of cycling through all formats to see what it is.
RptWithGeometrySpatialField.init doesn't call super.init and thus the shapeReader & shapeWriter isn't initialized. That's perhaps not a bug in this issue but it was a non-issue before and now it is. It's a challenging conundrum; ideally it would but I had difficulty with a cach-22 of extending it and also supplying it to CompositeSpatialStrategy. I can revisit that in a separate issue.