Forward secrecy does not protect the data for which the key was leaked (which could be at-rest data), it only protects future transmissions.

This is a common countermeasure. You need to be aware that you maybe just be moving the problem. In settings in which key agreement techniques aren't used you'll be deriving new symmetric keys from an initial secret using a KDF. You now need to make sure that the KDF is DPA-resistant.

Forward secrecy is defined with respect to key agreement schemes and not symmetric crypto per se.

"Algorithmic countermeasures" - that is, switching keys quickly - can indeed hinder side-channel attacks. Be careful not to introduce more problems than you solve, though - hand-rolling your own crypto is something to leave to a team of experts (because you definitely want someone reviewing your design!)