Blocking outbound traffic is usually of benefit in limiting what an attacker can do once they've compromised a system on your network.
So for example if they've managed to get malware onto a system (via an infected e-mail or browser page), the malware might try to "call home" to a command and control system on the Internet to get additional code downloaded or to accept tasks from a control system (e.g. sending spam)
Blocking outbound traffic can help stop this from happening, so it's not so much stopping you getting infected as making it less bad when it's happened.
Could be overkill for a home network tho' as there's a lot of programs which make connections outbound and you'd need to spend a bit of time setting up all the exceptions.
Most consumer firewalls block incoming connections only and allow all outgoing traffic. This is to make configuration easier; you enumerate what services you are running and want to allow, but you do not need to enumerate all the kinds of outgoing connections you want to allow.
Most Android devices do not run as servers. Setting up a server process that can listen and respond continuously breaks power-saving features. If you want to send data to an Android device, you get the Android device to connect to you, possibly alerting or sending via cloud messaging, which is a connection setup and managed for power-saving from the Android client-side.
What will a consumer firewall do for a device that isn't running services? Nothing, because there is nothing listening that you can block traffic to.
If you run server processes on your Android device, this situation obviously changes, but this is not the expected normal usage.
Most non-enterprise firewalls operate in one of two modes: NAT or bridged
NAT is the traditional topology that you're thinking of. The firewall has the only public IP on the network, and is translating between it and a private, non-routable class. In this case, machines "behind" the firewall have private IP addresses, and therefore are not publicly routable.
In bridged mode the firewall is configured to effectively cover an IP "space." This space is basically the network/netmask on which the IPs are located. For example, for the publicly routable class 74.52.192.0/29, which encompasses 74.52.192.1 - 74.52.192.7, can be configured on a firewall with the firewall interface having any address in the range. If the firewall is in bridged mode and configured as such, you will be able to have machines connecting as any of the other IPs in the 74.52.192.0/29 network (the one that the firewall is using is of course unavailable).
if the router is reporting your WAN ip as your public IP then you have a public IP assigned to you.
If you want to know who the provider is you can do a lookup as to who the owner is ARIN's lookup site if you are in the US.
As far as if you are behind a firewall - that will be more difficult since even if you did something like an nmap scan your belkin would probably drop the packets anyway.
You should also note that running servers is against every TOS i've seen on consumer level internet connections, and some providers (Verizon i'm looking at you) will filter common server ports (25, 80, 443, 110, etc)
Honestly if you want to run a web server the least headache would be to shell out the 10$ or so a month for a hosted website.
Usually firewall is a router, so normal configuration for router is have different subnets on different interfaces.
In Your diagram, as I guess, implied that LAN is private and WAN is public IP space, so "firewall" really do not only Firewall work (filtering) but also NAT-router work (routing and address translation).
But in some cases is useful to configure firewall as transparent bridge (switch) without making influence on subnets architecture.
