"Working fine" is indeed a great metric, but if you are the only one in the team able to decipher what you wrote, and thus maintain it, the code is close to worthless for the company for the mid or long-term.
A good code is at least :
- working as intended
- human-readable / clear
- easily maintainable
- easily extensible for future changes
- without unneeded dependencies
- handling correctly non nominal cases
(Some of these requirements are actually overlapping but are good to consider individually...)
Code reviews serve the purpose beyond the "working" part, which can be done through automatic tests.
I personally know this is annoying to have something working being teared apart, and having to rebuild it from the ground up. But, often, this is due to a miscommunication from the senior/tech lead. So, if you think you have to rewrite too often, next time, go to the reviewer before writing a single line and try to get as much information as possible on what he is expecting, in every detail. It could also be great if the team of code reviewers summarize their expectation in a formal document that every dev can refer to.
On a more positive side, a session could also be an occasion to share great practices/designs.