if the remote server is somehow compromised without me knowing about it, would the intruder be able to access my local computer when I am connected to it?
The high-level functions are not symmetric; things like shell sessions only work in one direction. The client will not respond to "shell" or "exec" channel requests coming from the server – it deliberately doesn't even have the necessary code to handle them.
However, there are requests that go in the opposite direction. If you connect with "agent forwarding" enabled, the client will allow the server to use all keys in your ssh-agent (though not retrieve the actual private key). If you connect with "X11 forwarding" enabled, the client will likewise allow the server to access your X11 window contents and possibly even spoof input. If you use Kerberos and connect with "GSSAPI delegation" enabled, the server will outright get a copy of your Kerberos credentials.
Additionally, if you still have an interactive shell connection (i.e. not using
-N or ControlMaster), a process on the server can send any data to your terminal so long as it has write rights to the /dev/pts/# device. Most terminal emulators generally will ignore "risky" escape codes (such as the OSC "run command" sequence being the most problematic example), but the server can still annoy you by making the terminal window move around the screen, by rickrolling you in ANSI art, etc. Finally, although the terminal emulators should be reasonably hardened against malformed data, they have had various exploits in the past.
Further, is the above mechanism for browsing local pages on my remote secure against eavesdropping and MIM attacks?
It does protect against both passive and active attacks along the path between you and the SSH server, as all data is tunnelled inside the SSH connection and gets the same protection (encryption and integrity) as everything else that goes over SSH.
It does not protect against attackers on the server itself, as the sshd has full access to the cleartext data it receives. (If plaintext data comes in, plaintext data has to come out, for hopefully obvious reasons.) The sshd can modify your data and it can even connect you to a different destination than you asked for.
It also does not protect against attackers anywhere along the path between the SSH server and the actual forwarding destination (the server's own OS being a possible attack point). You would still need the actual forwarded connection to use HTTPS to protect it.