Good question. Well for one thing, to remain backwards compatible with iOS 6, it requires code that's not very flexible. For instance, the meaning of "tintColor" is now different in iOS 7 than in everything else in iOS (6.1 and earlier). Setting a tintColor on a navigation bar would change the background color of the bar while applying the gradient. To do that now, all references have to be set to "barTintColor" or other depending on the view. The tintColor property now refers to the color of text and icons in the bar and cascades through the view hierarchy.
The app I develop is for musicians and used on-stage. We've experimented with different designs and found that large touch zones and bold/large text is important for proper usability. iOS 7 reinforces what I feel is bad design language for this scenario... light typefaces, small text labels that don't appear as buttons and thin icons. All of this combines into what a lot of my users refer to as "unusable" given the situation they use the app. I haven't updated the UI of my app because I'm working on a complete UI redesign anyway, but from initial focus group tests, iOS 7 fails in that regard. I'm not sure if deviating from the style guide will cause issues.
It's also littered with bugs (still). I've had to workaround a number of issues that are caused by threading concurrency. For instance, I need to load a UIWebView on both the main screen and an external screen. Doing this in iOS 7 causes one of the UIWebViews to not render and it's not predictable. The only way I can force this to work is to delay the drawing of the external display by a second or two. This is bad programming practice, but it appears that running more than one UIWebView at once will cause issues. I'm experiencing bard crashes when display Word DOCX files. This is due to a read error deep in the iOS codebase and not something that can be worked around. There are some bugs regarding underlines text in NSAttributedString, poor performance and dropped packets in GKSession (GameKit Framework) and more.
Now, if I were coding an app from scratch and not supporting non iOS 7 devices or weighed down by these legacy features, I'm sure things would not be as "bad"... but I'm trying to maintain a user base, 15% of which use iOS 5.1 (iPad 1) and 15% of which use IOS 6. Shockingly, about 60% are using iOS 7 at this point.
So, I'm redesigning the app. What does that mean? It means recreating ALL of my tutorial videos, help documentation, screenshots and more... in 14 different languages. Bad for developers is thousands of dollars worth of rework because Apple wants my app to fit in. All this while I'm working on a 2.0 version where I have to do that anyway.
So that's my explanation of "bad". Oh, and to the gentleman who called me "lazy" and that I "don't like change"... how about making an app that's in the top ten list of paid music apps and requires 60 hour weeks... then you can talk to me.