It's often important to ensure that login occurs over HTTPS instead of HTTP, while the rest of the Trac site can remain served over HTTP. Currently the only way to do this is with rewrite rules in the front-end web server, as described in trac:ticket:4733
A solution within Trac was proposed on that ticket, relying on a new trac_login_uri setting to generate https links to login. However, that solution would not prevent users from manually visiting the http:// login URL without following a link, and would also require that any plugins which generate login links (including PermRedirectPlugin) be updated to use the new method.
A more secure-by-default approach would be to use a request filter that intercepts requests to the login page and redirects them to the HTTPS version of the same page. Of course this would not prevent users from manually POSTing credentials to the login page over HTTP, but (a) this would have to be a deliberate choice because the login form itself would only ever be served over HTTPS, and (b) in scenarios where authentication occurs within the Trac environment (e.g. AccountManager login as opposed to Apache authentication) the POST request itself would also be intercepted, so the response would not leak any information about whether the credentials were valid.
Since this is conceptually similar to how PermRedirectPlugin handles its current feature-set, I think it makes sense to add this feature to PermRedirectPlugin as well.