I like the Object Browser. It gives me a quick glance at my tables, views, etc., and I don't need to fire up SQL Developer or Toad to get to it. When I'm developing an APEX app, I'll often have the Object Browser open in another tab or window (often window, so I can flip to it with alt-tab). And it applies syntax highlighting to the code for views, procedures, functions, etc., a feature that is sadly missing in the SQL Commands screen–sometimes I'll create a null procedure/function in the SQL Commands window, and then pop into the Object Browser to actually write the code. It's a great little tool.
Yep, there's always a but, isn't there?
I got burned (and scared) by the Object Browser last week, I was working on a new feature, and I added a column to my core users table. To test, I edited my row in the user's table in the Object Browser, because I was too lazy to pop over to the SQL Commands screen and type up a real update statement. Big mistake. It turns out that, when you edit a table directly in the Object Browser, it's rather indiscriminate about which fields it saves–it seems to save them all, regardless of whether or not you've changed them. 99% of the time, this isn't going to be an issue. Unfortunately, this was one of the times when it was.
The problem is that I've got the user's password stored in the users table (where it belongs), and for security, the password is encrypted. When the Object Browser displayed the row, it attempted to show the password, but the encryption creates a lot of non-printable characters (of course). So when the record got saved…the encrypted password got written over with true gibberish. And I found myself locked out of my account the next time I tried to log in. Since I didn't try to log in until well after I'd updated my record, it took me a while (panic made it feel roughly ten times as long as it really took, I'm sure) to figure out what had gone wrong.
So, be careful of updating records in the Object Browser…there can be unexpected consequences.