see from the gerrit review....
Both of the topics revolve around the information that TYPO3 should not consider any of these parts as "cacheble" or "success". But this is highly dependent on the context.
How would a developer know if a status code showed up? We're lacking lots of proper configuration to inform the developer that there is an issue.
I give you an example: Somehow a developer added a plugin "World Clock" into each page on the right sidebar. Now, the rest of the page shows up, gets cached etc. and still works fine. But the World Clock plugin is only compat with e.g. PHP 7.2.4 or lower but not with PHP 7.2.5+, and the hoster just updated the PHP version - this would make all the pages (which show proper content for the rest) as an error PLUS open up the risk for DoS due to not caching at all. However, the developer is out-of-office / on vacation but put this thing in TypoScript, so the editor cannot remove it - would you consider caching this and sending out 200-response? I would.
But of course, having a faulty EXT:news because a newly added news, should result in a 500 on the detail page because of a manually removed image. Stuff like that makes it hard to find the right path here. Both options are valid, but the current status does not open the door for DoS, which is the main benefit for me in terms of "strong default".
Updated by 
Updated by