Peeping at the 'Working with HTTP/2 in Burp Suite' to find out why the option to strip the connection header exists, I found the reason to be 'This is because many HTTP/2 servers will reject requests containing this header.'.
Is there a specific reason for that?
Yes, the HTTP/2 specification states, in section 8.1.2.2:
HTTP/2 does not use the Connection header field to indicate connection-specific header fields; in this protocol, connection- specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed
Having said that, many servers are more lenient and tolerate Connection headers to be present, although they are ignored.
The reason for this restriction is that the Connection header makes sense in an HTTP/1.1 request, where one request at a time was sent over a TCP connection.
In a multiplexed protocol like HTTP/2, it does not make sense for a request (a HTTP/2 stream) to carry connection headers, because there may be multiple requests on the same TCP connection.
As an extreme example, if you have an HTTP/2 stream with Connection: close and another, concurrent, HTTP/2 stream with Connection: keep-alive (although keep-alive is deprecated even in HTTP/1.1), what should an HTTP/2 implementation do? Close the connection as the first stream suggests, or keep it open as the second stream suggests?
Clearly this is not applicable to multiplexed protocols like HTTP/2, and that's why implementations reject such requests.