The original bug was a way to compose query string parameters (the part of the URL after the ?) that permitted injecting executable code in a form. The new bug is a variation where the malicious query string is part of a redirect URL passed through the query string, so it doesn't get filtered with the previous patch, because it has escaped characters. So it's not really a new bug, but rather plugging an oversight on the original patch.
On the positive side: Drupal has security audits of its core and 3rd party components, you get emails with any security updates and the patches are available through a centralized mechanism... so it's ahead of Wordpress and other platforms with no centralized module library. Release of the patches was announced ahead of time so we could prepare for them. I
On the negative side: Drupal has fundamental architectural problems of (almost) not having boundaries between data and code. It's form API (which had the original bug) is very practical and implements a lot of great security features, but it's an unfathomable mess... VERY hard to track what it does and very hard to properly use (for 3rd party module developers), since its internal workings are not properly documented. Also, Drupal has a very very extensible architecture allowing for all sort of pluggable behavior, which also means it's very very hard to track the flow of data... this was a bug present at least since Drupal 6 (released in 2008) because it was not easy to see how data could move from the query string into the PHP structures used to define forms without proper filtering. The new-ish Drupal 8 has a more mature OO architecture, probably cleaner, but even harder to follow without actually running the code with a debugger.