As programmers, we do see too often those "smart professionals", engineers, land surveyors, designers... over-use (if not abuse!) Excel to store their mission-critical data and hard to sell them better and safer alternatives. Sometimes a programmer can decide, sometimes cannot.
However, as CAD programmers, whether we have a say or not about where/how data is stored, we should focus on making our solution structured correctly first, which I have not seen being mentioned in the discussion of this thread.
By structured correctly, I mean that the typical of solution of this kind would consist of 3 parts: code to manipulate objects in AutoCAD/Drawing, code that passing data between AutoCAD and data store, and code that actually organize the data store (especially, if it is your own custom data store, such as Excel sheet, CSV, XML...).
The key part is the middle one: data access layer. It should be coded against an Interface so that the from part (AutoCAD side code) would have no knowledge on what the back end is, be it Excel sheet, or some kind of database. That way, if the back end data store is changed, simply implement the interface against the new data store, and the CAD side code (reading/writing data back and forth) will not be affected and not need to re-build/re-compile.
With that said, however, if you use VBA, I am not sure if you can use Interface. Back to when I was using VB5/6, yes, one can define Interface and implement it. By why still sticking with VBA?