It would seem one of the most obvious colloquialisms is only alluded to by other proposals.
That is, you can use the following:
bash -c '$PROG_WHICH_MAY_FAIL ; (true)'
in order to "force success".
Note, this is along the lines of the proposal by lornix (just not in so many words).
Anyway, since this is effectively ignoring the actual process exit status, I'd make sure you consider somehow saving the sub-process status for post-mortem analysis. E.g.:
bash -c '$PROG_WHICH_MAY_FAIL || touch failed; (true)'
true here is somewhat redundant and so this may be better written as:
bash -c '$PROG_WHICH_MAY_FAIL || touch failed'
Since we probably would like to know when the 'failed' file couldn't be touched. In other words, we're no longer ignoring the failure, we're taking note and continuing.
And, after considering the recursive nature of this issue, perhaps we see exactly why xargs does not make ignoring failure easy. Because it is never a good idea - you should be enhancing the error handling within the process you're developing instead. I believe this notion, however, is more inherent in the "Unix philosophy" itself.
Finally, I suppose this is also what James Youngman alludes to by recommending
trap, which presumably could be used in a similar manner. That is, don't ignore the problem... trap it and handle it or you make wake up one day and find that none of the sub-programs succeeded at all ;-)