Redirect on email login not working

My guess is that you have the "Encrypt Login Form" setting enabled in the SCLogin module options. In that case, if the user is on the http:// page and try to authenticate, they'll be redirected to the https:// site. That shouldn't prevent the redirect from working by itself, but many sites (and servers) have additional rules which can cause the behavior your mentioning, like stripping extra variables from the GET request or an .htaccess rule regarding SSL connections on the site.

Disabling the Encrypt Login Form setting will leave the user on whatever version of the site they were on when they tried to authenticate.. though their credentials will be passed in clear-text over the internet.

The other option is to disable the http:// site altogether and force users to the https:// version always. It's what we do and what many sites are moving towards to ensure that all traffic, even for guests, is encrypted.

I hope that helps,
Alex

because we're worried about the performance on our server.

That's understandable. However, the idea of it being a bit hit is generally a myth. While there is some hit, of course, it's very minimal on almost all servers nowadays. Of course, if you're on the cheapest hosting plan possible, you probably are already running into other performance issues. For a breakdown, see:
www.maxcdn.com/blog/ssl-performance-myth/

As a bonus, Google has even noted that pages that are loaded over SSL get a (very tiny) ranking boost:
googlewebmastercentral.blogspot.com/2014...-ranking-signal.html

Would you happen to be able to give us a hint or tip as to what type of rules we would have to search for in our .htaccess file?

I really wouldn't. You'd need to check the routing of the logout flow to determine when the redirection or stripping of the query string occurs. It could be in various places. Of course, disabling SEF URLs and temporarily removing the .htaccess file removes a lot of possibilities quickly.

I hope that helps,
Alex

Loading other assets can definitely be a hassle. In general, most 3rd party libraries from Google or other sources can be loaded over http or https, but of course, each needs to be confirmed. Best practice on your site is to load assets using a 'schemeless' link, like:When a link starts with //, it instructs the browser to load that resource with the same scheme as the current page. That way, users on http will get http assets and ones https will get the secure version. Of course, then you just need to make sure wherever the asset is being loaded from supports https.

As always, I hope that helps, but if you need anything else, just let us know.

Thanks,
Alex