Why does grepping the same manpage sometimes results in an error?

Because the -z option is used, the first grep appends a NUL character to the end of the output. What happens next depends on the vagaries of buffering. If the second grep sees that NUL before analyzing the file, it decides that the file is binary. If it doesn't, it finds the match that you want.

So, this happened to work for me:

$ man curl | grep -Pzo 'EXIT CODES(.|\n)*AUTHORS' | grep '  6  '       6      Couldn't resolve host. The given remote host was not resolved.

However, if I put the output of the first grep in a temporary file and asking the second grep to read that, then the second grep would always complain about the input being binary:

$ man curl | grep -Pzo 'EXIT CODES(.|\n)*AUTHORS' >tmpfile;  grep '  6  ' tmpfileBinary file tmpfile matches

Alternative: use awk

One way of avoiding the NUL character issues, as well as reducing the number of processes required, is to use awk:

$ man curl | awk '/EXIT CODES/,/AUTHORS/{if (/   6   /) print}'       6      Couldn't resolve host. The given remote host was not resolved.

Alternative: use sed

$ man curl | sed -n '/EXIT CODES/,/AUTHORS/{/   6   /p}'       6      Couldn't resolve host. The given remote host was not resolved.

Alternative: use greps and tr

As tripleee suggests, another option is to use tr to replace the NUL with a newline:

$ man curl | grep -Pzo 'EXIT CODES(.|\n)*AUTHORS' | tr '\000' '\n' | grep '  6  '       6      Couldn't resolve host. The given remote host was not resolved.