Hakuna matata!

Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist.

Wenn ein Angreifer den Verkehr wirklich mitschneidet, dann kann man davon ausgehen, dass dieser auch die Server-Antwort zu sehen bekommt, in der dann auch schon die neue Session-ID übermittelt wird. Der Angreifer könnte daraufhin sofort eine neue Anfrage an den Server senden und damit den regulären Nutzer aus seiner eigenen Sitzung aussperren.

Siehe dazu auch: http://forum.de.selfhtml.org/archiv/2014/3/t216939/#m1489011

Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.

Das hat man doch schon dadruch erreicht, dass die Credentials nur einmal fällig werden und danach auf Session-ID zurückgegriffen wird, um den Nutzer erneut zu identifizieren. Was trägt es da an zusätzlicher Sicherheit bei, die Session-ID ständig zu erneuern?

Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist.

Also mir sind keine Perfomance-Bottlenecks von HTTPS bekannt und dem Tradeoff Sicherheit für Performance kann ich auch im Allgemeinen nicht viel abgewinnen.

Wenn man session_regenerate_id() zudem bei jeder Anfrage ausführt, dann können keine Anfragen des selben Nutzers mehr parallel bearbeitet werden. Denn wenn die zweite Anfrage eintrifft, ist die Session-ID von der ersten Anfrage bereits für ungültig erklärt worden.

Auch dazu hatte molily schon mal ein paar Worte verloren:
http://forum.de.selfhtml.org/archiv/2014/4/t217253/#m1491970