What are the advantages to animating eyes directly as objects as opposed to via an armature?
I will try to list some advantages which aren't opinion-based. There are basically four different methods of rigging the eyes.

Having a separate control object/armature for the eyes

Just for the record, this would be by far the worst idea. It includes
(1) having an extra armature for the eyes which is connected to the main armature
(2) having an extra object to control the eyes in conjuncture with another armature
(3) creating a rig without any armature.

To animate (in Blender), armatures have many benefits.


copy and paste poses
mirror poses
inbetweening tools (breakdown, push, relax)
propagate poses and using libraries
Even after connecting the armature to geometries, the bones rest position can be modified without a problem. If you are using standard objects which are connected by parenting, moving any of the will be a lengthy process which involves unparenting and reparenting.


Another disadvantage of multiple objects in combination with armature can be dependancy problems, where the order of influence is not supported by the way Blender is designed.

This method should only be used, when the desired deformation is not achievable with bones and shapekeys, in which case helper objects (like Lattices) are unavoidable. For non-deforming eyes, there's no reason to use anything other than bones.

Parenting both eyes to the head bone

This is includes most of the aforementioned problems. To reiterate


You won't be able to see all animation-relevant keyframes easily; the action editor works best with a single armature. Otherwise you would constantly have to select both objects to see the selections in the dopesheet, or find another way to organize the dopesheet. In extreme cases Animation Curves can be rearranged by renaming the, while the order in the dopesheet will depend on the actual objects' names.
You can't use the pose tools mentioned above. (Mirror, Copy, Pose ...)
You will have a hard time synchronizing events. The eyes and lids are always going to move in conjunction and it is important to have good access to both at the same time.
Pose bones have selection priority over geometry. If your meshes are not well positioned next to bones, you will have problems selecting both equally.
If you select a mesh-type object after selecting an armature, the armature gets highlighted as one, and you cannot see which bones are selected.


Parenting each eye to its individual control bone


The advantages mentioned above: the pose tools, the action editor behaviour, no dependancy problems
Access to bone constraints for the eye controls.
Scripts which interact with user selections get easier the bones matrix functions all act the same and the examined selection is a subset of the one armatures pose bones.


Controling the eyes with a single armature modifier

(*As expected, I'd prefer this approach wherever possible.)


All of the advantages of the previous method.
The influence of rig can be toggled on and off by toggling the visibility of the armature.
The eyes transformation are no longer relevant. Their origin can be set to (0, 0, 0). If they are accidentally moved, they can be reset. In Blender, on can not know where an objects origin is from only it's transform values. Next to Direct and Inverse Parenting the original location of the object will play into these values. With bones, their rest pose position is automatically "zerod out".
Exporting a rig (to fbx for example) is "safer", when all objects are zerod out. Combinations of parents can produce transformation which have to take many values on many objects into account (see previous bullet point). This is not always handled correctly by all exporter or other systems.
Finding the geometry in the outliner is easy, because it won't be hidden in the hierarchy.

Armatures work with Blenders linking and proxying system.


As always, there are exceptions: For some quick straight-to-the-point rigs, manipulating the objects may be an option.



I will try to include some more information, based an a comment: 


  [eyes (which are not controled by an armature)] are controlled with an eye target, which the objects damped track. This is [...] basically the same as sticking a damped track on bones.


This holds true, unless - later on in production - more features get requested.


If the eyes are no radially symmetrical (due to a texture update), they will need an Up Vector, otherwise they would rotate in their sockets. This can be easily done with the Pole Vector of an IK constraints with bones. With objects, you will need more steps.
If the model of the eyeballs changes and needs different handling of various rotations, all previous animations are lost. With an armature, on could easily keep the animated Control Bones and transfer the data over to the deformation bone with a driver.
If the animation if supposed to be fixed1, there are no available controls. The eye_targets are going to be to far away to properly control the eyelid and eye interaction. In the case of armatures, and additional control bones can be added into the hierarchy, between the deforming bone and the bone, which is oriented by the target.


Also...
- the empties are still not going to be in the armatures action, making the pose tools (copy, breakdowns, mirror) and linking system (appending actions) useless.



1 An animation fixer is the animation assistant who will do the fine tuning on finished animations. Doing slight tweaks to prevent wrong interpolations or intersections of character and props.