Why is a session ID as security-critical as the strongest authentication factor used during login?

Once issued, the session ID is the "bearer credential" — whoever has it acts as that user. So it deserves at least the same protection level as the password or token that produced it.

If you ask for username + password + TOTP at login (strong), but then hand out a session cookie that travels over HTTP, the chain is only as strong as its weakest link — the cookie. Whoever sniffs that cookie gets the same access as someone who knew password + TOTP.

What "protect the session ID like the strongest factor" means in practice:

• Transmit only over secure channels — HTTPS always, Secure cookie flag, never let a session ID round-trip over HTTP. Critically: never switch session ID between HTTP and HTTPS. If a page is HTTPS but loads an HTTP sub-resource that includes the cookie, the cookie leaks.
• Use HSTS to ensure the browser refuses HTTP even on stray links.
• Mark cookies HttpOnly so a stored-XSS bug can't dump them via document.cookie.
• SameSite=Lax/Strict so they don't ride along on cross-site requests (CSRF defense).
• Short timeouts so a stolen cookie has a small useful lifetime.

Tip: If you wouldn't email someone their password, don't let their session cookie travel over HTTP. They're the same kind of secret, with the same blast radius.