Yes, cards as game objects (or collections if you need more complexity in how the card visuals are created).
Maybe. You could also use a data driven approach where the card properties are stored in a Lua data structure and set by a central card handler script.
Yes, absolutely!
Again, maybe. It would require a script per card which isn’t strictly necessary (see note on properties vs central data structure).
It is very tempting to use properties and a script per card. It can feel good to think about things in an object oriented fashion. “The card is an object and I should therefore put the data and logic belonging to it in a script on the card.”
This is the way to do it from an OOP standpoint, but it doesn’t scale well. What if you have several thousand objects? You’d then have logic and data in a thousand places. You’d make the transition from the engine code to the Lua logic in each script a thousand times (expensive).
You could instead put the logic in Lua modules/functions, keep a list of all cards and their data in one place, and update the cards from a single script.
I’m not saying that one is superior to the other in all cases. You need to make a decision based on the game you are making. What are the rules and restrictions of your game? Will you only ever have a deck of 52 cards in play at any given time? Or will you have several hundred cards in play?