The general recommendation is to have all members of a cluster or replica set running the same version, inclusing arbiters. Hence, generally you should upgrade arbiters when you upgrade everything else. In fact I would say to upgrade them first since if you have things configured correctly there will be no interruption in terms of operations from an arbiter upgrade (barring an outage elsewhere while you work).
They will probably work just fine with mixed versions, but since you would be then running in an untested (for long term use) configuration, if you run into any issues at all the first advice is going to be: upgrade.
Upgrade Requirements
To upgrade an existing MongoDB deployment to 3.0, you must be running 2.6. If you’re running a version of MongoDB before 2.6, you must upgrade to 2.6 before upgrading to 3.0. See Upgrade MongoDB to 2.6 for the procedure to upgrade from 2.4 to 2.6. Once upgraded to MongoDB 2.6, you cannot downgrade to any version earlier than MongoDB 2.4.
http://docs.mongodb.org/manual/release-notes/2.6-upgrade/
One of the most important thing to remember after you are on 2.6 if you are trying to use WiredTiger as your storage engine, you do need to take a mongodump by connecting into current mongodb version and then switch to mongodb 3.0 with a different db path,
IMP: You will not be able to use existing DB path as previous storage on mmapv1
Command to use: mongod --storageEngine wiredTiger --dbpath
mongodump and mongorestore can operate against a running mongod process, and used to take a backup and restore the backup respectively.
http://docs.mongodb.org/manual/reference/configuration-options/
storage.engine
Default: mmapv1
New in version 3.0.0.
Specifies the storage engine for the mongod database.
Valid options include mmapv1 and wiredTiger.
If you attempt to start a mongod with a storage.dbPath
that contains data files produced by a storage engine other
than the one specified by storage.engine,
mongod will refuse to start.
Best Answer
In general, yes, you can do this, the 2.4 binaries can be used as drop in replacements. However, there are exceptions. In sharded clusters for example, you have to make sure to do the meta data upgrade
Essentially, the caveats are all really deployment and feature (authentication), not version based. Basically make sure to read the notes here:
http://docs.mongodb.org/manual/release-notes/2.4-upgrade/