Take note that every time you write JS script, it is automatically a class, which is derived from MonoBehaviour, and have the same class name as the name of the file (and name of the behaviour), so you are always using classes.
You define your own classes manually, like this
class FooBar {
}
You define your own class explictly when you are sure you don't need Update(), Awake() and such functions (all behaviours' Update() is invoked once per game logic update, Awake() is called when the game first began and so on). I usually defined my classes manually when they are not game objects - for example, consider the Vector3 class. It does not need to be updated by the game constantly; so use a manual classes for data structures, game information and etc.
About your question, of designing the class Plant, it is good to keep in mind Unity3D is designed along a composite pattern. Instead of inheriting, you put different classes together to give each game object an unique behaviour. So don't think of having a 'plant' class, think along the line 'how can i break this plant down into discrete, reusable components?'
For example, I have three spaceships, one is a supply vessel, one a missile frigate and another a battleship with a massive cannon. What is common to those objects? A movement component/script. There should also be a missile component for firing missiles, and one for cannon firing.
So to put together the missile frigate, I take the basic movement script (class or component, it's just terminology), and the missile firing script, and put them together. For the battleship, I put the cannon and the basic movement together.
The power of this is that if the next time I want an awesome battleship-missile-firing supership, I just put the missile and cannon component, and code a battleship-firing component, and put together on to the same ship.