I guess what we would have expected to see either somewhere in your vse.log or in the inspection view or in ... is a java exception message, for example something as follows:
"exception is java.lang.IllegalArgumentException: Incoming request is not HTTP."
For example the above is often thrown when a IT Management vulnerability scan tool hits the virtual service. It does a call on the port but it isn't an HTTP call.
Because when you have some exception like the above then the HTTPS Listen Step is not able to create a lisa.vse.request object. And if you have no lisa.vse.request object then filters or DPHs will also throw errors because they need an existing lisa.vse.request object to work upon. So, I believe that the 'JSON Path Filter' error that you posted above is a secondary error and not part of the root cause.
So, no, I do not expect that JSON 2.0 DPH will resolve this error because it also needs a lisa.vse.request object.
If you already want to start digging for the root cause then I suggest that you change the "if environment error" assertion not to "end the test" but let it go to some additional step(s) that you can add to the .vsm. Then after that additional step you can end the test.
You can "query" the environment (testExec) and various properties in that step and try to write something to file which could point you to the root-cause.
Try looking at lisa.vse.request property, and lisa.vse.http.current.transaction.body as suggested by Prema. (But again, I expect those properties to be null)