I agree it would be good to make the changelog unreadable but what are the numerous other ways it's insecure by default? As for the rate at which vulnerablities appear, Drupalgeddon was a very rare case. I haven't noticed Drupal having security issues noticeably more often compared to other software, what are you basing that claim on?
Insecure by default might be slightly unfair... but insecure by design might be more accurate.
A concrete example: the Drupal convention is to move as much behaviour as possible out of code and into configuration. This configuration is generally controlled by admin panels. Eg, if you have access to administer Views, you basically have access to export pretty much any content to anywhere in whatever format you want.
I think that's a pretty crappy design. If you believe that this sort of administration is useful, then you want to have user accounts with permission to do it. But then if you do that, any account with those permissions is an enormous vulnerability.
I get the benefit for some use cases. I just think that (like a lot of things in Drupal), it has pretty unpleasant implications for a lot of situations. Maybe not critical by itself... but it feels like at every layer of Drupal there's some shortsighted design decision that encourages insecurity.
Thanks for giving an example. I'd say that you can definitely take advantage of the functionality provided by views without having accounts that are able create and modify them on your production site. In fact it's accepted as the right way to do things.
Without more serious examples I can't really agree with your conclusion that it's full of design decisions encouraging insecurity. When it comes to serious security issues that have needed patching I'd say Drupal has a fairly decent track record. It certainly has better defaults and less serious security issues compared to WordPress. I admit that is not saying much but WP has been becoming more and more popular as a CMS and that is what Drupal often gets compared to.
