As you rightly suggest server parameters are based on a polling system whereby the Parameter server is polled by nodes to retrieve information loaded on startup (or during execution). This may be inefficient if the information doesn't change. Dynamic reconfigure utilises a callback that is called when the parameters are changed via a gui, hence it is more efficient than polling if we are expecting values to change.
As for why there are both. I'd expect that server parameters were developed first, and then dynamic reconfigure developed as an additional feature. Server parameters are useful particularly when parameters dont need to change during execution, and between runs, the config files can be updated without recompiling code. Additionally server parameters are a little easier to implement.
Dynamic reconfigure is useful when tuning during execution. But does require another node, either rqt_reconfigure or a dynamic reconfigure client to be implemented in order to send the changed parameters. If a parameter changes so much perhaps it is more efficient and simpler to implement a serviceServer/client or subscriber/publisher linking information between two nodes. Otherwise if using rqt_reconfigure then it requires a human to drive the gui, which is usually not what is required in robotic implementations.