Although it's Firefox are Safari are supported in the latest version of SharePoint, you can't edit documents directly from the portal (and probably Excel Services won't work either, but I haven't tried it). Taking into account that document libraries are the most useful part of SharePoint, and they only work in IE, well, yeah, it works, but you wouldn't use any other browser unless in an emergency.

Moreover, I pity the poor programmers currently involved in SharePoint. Have you seen the HTML that it generates? It was written for IE6, in quirks-mode, and it continues that way. That means that everything having to do with HTML and CSS has to be written at least twice, because padding, :hover events (on non-A elements) and many other things we now take for granted are either not available in quirks-mode, or work differently across browsers.

And if you develop anything on top of SharePoint, well, you don't have the option to use valid HTML, so welcome back to the year 2000! In the end, the overhead cost of developing for multiple browsers in this mode means that most customers are quite fine if their custom apps (that work on top of SharePoint) only work on IE. In fact, many useful third-party addons (ej. Nintex) only work in IE.

Hopefully, SharePoint 2010 will fix this, and I'm quite sure that SharePoint is going to be a great product some day. But just right now, it sucks in too many areas, and it has a major handicap to overcome: shared folders are easier and faster to use.

It hides from the developer that you are actually doing something that could be costly.

For example, that innocent "item.price" could actually be calling an stored procedure that makes all kind of querys to get the right price for the current session customer.

In Java, item.getPrice() would be a hint to this fact. In C#, someone could abuse the property, in different instances of the same item, unaware that he should cache the value to avoid performance hit.

Of course, there are ways to prevent this, but are mostly related to procedures the developers must follow.

Actually, while I really like C#, LINQ, and Visual Studio on the whole (I'm quite happy developing with it), I'm starting to understand why Java had some things that forced the programmer to be explicit about what his/her code did. Not forcing you to catch or throw exceptions means, for example, that methods that couldn't throw an exception (according to it's definition) actually throw them. And you didn't put a try catch because it was a simple call and there were no methods that could throw...