What's costly in HTTPS is the handshake, both in terms of CPU (the asymmetric cryptographic operations are more expensive) and network round trips (not just for the handshake itself, but also for checking the certificate revocation). After this, the encryption is done using symmetric cryptography, which shouldn't impose a big overhead on a modern CPU. There are ways to reduce the overhead due to the handshake (in particular, via session resumption, if supported and configured).
In a number of cases, it's useful to configure the static content to be cacheable on the client-side too (see Cache-Control: public). Some browsers don't cache HTTPS content by default.
Increasing the server's CPU load by 300 when using HTTPS sounds like something isn't configured appropriately.
His solution was to only use SSL on the login page to secure the
transmission of the login credentials. Then redirect them back to
HTTP...Is this good practice?
A number of sites do this (including StackOverflow). It depends on how much security is required. If you do this, only the credentials will be secured. An attacker could eavesdrop the cookie (or similar authentication token) passed in plain HTTP and use it to impersonate the authenticated user.
Great care needs to be taken when switching from HTTP to HTTPS or the other way around. For example, the authentication token coming from the login page should be considered as "compromised" once passed to plain HTTP. In particular, you can't assume that subsequent HTTPS requests that still use that authentication token come from the legitimate user (e.g. don't allow it to edit 'My Account' details, or anything similar).
