You're wrong.
You're blunt response and equally poor tone certainly didn't aim to reduce any potential flame fest, but point taken.
In other words, names define mechanics.
A rose by any other name is still a rose. Names don't define mechanics. A mechanic exists outside of whatever name is chosen. Once chosen, a name provides flavor and something for the user to latch onto as a way to get some instinctive understanding. One of the common things I run into in software engineering is once someone "names" an approach, thinking becomes limited and funneled by the context of the name.
I've lost count of the number of times a coworker keeps saying "I need this real contact in our customer acceptance test database". I say, "OK, I'll put it into the mock database we expose to customers for that." He goes "No, it can't be mock, it has to be a real person."
*palm forehead* He's stuck on the word Mock, his thinking is thrown off by the context of that word.
You call something "lightning" and you've reduce your scope of what can be done with that mechanic. Debating "lightning" versus "electricity" at this point is losing sight of the design goal, which appears to be some sort of elemental (e.g. semi-natural) damage mechanic.
A big goal, I'd guess, is the feasibility of the game mechanics? 5 elements, 10, 20? What does that imply for game logic and micromanagment. Some placeholder names are sufficient for now as general ideas to grasp the scope of the work.
When the game gets published, you want nice instinctive names. Debating that detail now is missing the point.