It very much depends on what you're seeing in JHOVE as an error - different issues would/could/should be addressed in different ways.
Without knowing the type of error its difficult to assess the impact of the error, and then further to know what action to take...
Some errors I would argue are completely ignore-able. Anything of the "warning" type is likely to be largely inconsequential (N.B. - likely). E.g. the DateTime field is not completed using the expected separator.
Some errors have significant impact on the intellectual 'essence' (E.g. non embedded fonts leading to a font substitution to a sub-par font, resulting in the visual loss of special characters (eg maconised chars such as "ā" or "ō")
Finally, some errors do result in an inability to render the file (not the case here, but worth acknowledging), e.g. missing EOF maybe because of an incomplete file transfer resulting in a partial file that is missing binary data.
From a practical perspective, we've been encountering this issue for a number of years as we ingest files into our preservation system. Initially we noted every instance that we encountered. This resulted in some nice data that showed this issue (of JHOVE failing pdf) is found across all pdf types that get ingested, and at a anecdotal rate of about 1 in every ~250 being flagged by JHOVE as having an issue of some sort.
We currently programatically ignore the flag from JHOVE if we can render the file. If we can render the file, we assume complete fail, and look into the file specifically. When we ignore the flag, a record is keep that a file was given an error by JHOVE, but the file is allowed to proceed unhindered into the perm storage. By ignoring the flag, we are essentially making a statement of intent that says "We acknowledge there is a potential risk with this file - we are currently unable to isolate the specific reason for the error, nor diagnose any specific long term risk for the content of the file. We will return at some point to the issue when either (1) we are sufficiently equipped with tools to address the challenge, (2) we have raised the generic risk against the pdf file type high enough that it becomes our priority action to explore/fix/mitigate or (c) we have run out of other things to do...".
As a principle. we would always retain the original file as it was first deposited - regardless of the ability to create a 'cleaner' version.
Its also worth thinking about what the constraining factor hear actually is.
What is the threshold test for creating a 'valid' digital object. On the one hand we have "Conforms to the exact specification"(JHOVE) on the other "Functions as expected across a representational set of object renderers" (Renderability test).
This notion of validity is at the very heart of what we are trying to achieve here, and I think personally that validity is not a binary thing (either valid, or not valid), there is a huge grey area in the middle that we work in on a daily basis and often we have to err on one side or another because of systematic/programmatic/circumstantial factors, when sometimes the decision might be better left on hold to allow knowledge and experience to influence the decision when its crunch time...