Not really. Certain parts of the language seem like a pain until you see all the possibilities for their use.

Let's take schemas. Most people, most of the time, use dbo and nothing else.

You can get imaginative with it.

dbo.TableA

security1.TableA

security2.TableA

Three tables, all named TableA, but, you have to supply the schema to get access to them. Or, are they three tables. I could have a table, dbo.TableA, and then two views, each called TablA, but with different schemas. Then have your reporting tool only log into and have access to the security1 schema (or security2). It'll see something it thinks is TableA, but inside you have code that blocks off or rewrites sensitive information.

So, if you're in the dbo and nothing else use case, yeah, it's a minor pain (one that goes away eventually). But you wouldn't want to take away the ability to do other stuff. If you're doing other stuff, the language has to support it. That's why you have to do the schema name.