Generally speaking, you're not going to have as many neat toys with postgresql out of the box as you will with Oracle.
But, in terms of load handling, a typical small postgresql server can handle dozens of financial transactions a second, and large ones can handle hundreds a second. Maximum connections in a default setup is 32, but that can be changed fairly easily to a 100 or so with little or no server / dbms tweaking.
Learning how to configure and tune postgresql, like any database, will take a little time and effort, but it can easily handle the number of users you're currently considering using it for.
But there are some important caveats. First and foremost is that postgresql currently doesn't have built in replication abilities. In a future version it will, and there are some "bolt on" replication services for it that work well for most applications, but it isn't in the same realm as Oracle for failover / clustering / replication.
Now answers to your questions:
1: Postgresql would be a good choice for ERP style applications. It's stable, moderately fast when on a large box that's been tuned for large databases. It supportsd transactions, triggers, constraints, and stored procedures.
2: You can write web enables applications for postgresql quite easily. If your users all connect via one web server and dbms server at one location, then the system will likely be faster than if you put a bunch of web servers all over and have them all connect via WAN link to the one dbms server. But, I see no reason you can't do it that way.
3: The maximum users you can connect to postgresql is 1024, and requires you to compile the postgresql package with a switch (--with-maxbackends=nnnn) that tells it the max it can have. For more than that you have to edit the source files and then use the maxbackends switch. I have had postgresql running with >750 connections under test, and while the individual sessions were quite slow (>30 second response), the aggregate bandwidth was still quite good.
Generally speaking, handling more than a few dozen connections requires that both postgresql and the server it will run on be "tuned" to handle the task well. This is covered in the administrators guide that comes with the postgresql tar file.
4: There is no default web broswer front end, but there is a project caled phppgadmin that was hosted on www.greatebridge.com, but that site is no longer online, and it seems a little hard to find a place to download it right now.
5: The report writing tool for postgresql is whatever you feel like writing. :-) There is a simple front end that comes with it that runs in tcl that is called pgaccess, but it's not really designed for overly complex reports and access.
