I think you should take into account that personal geodatabase is created and accessed through ESRI clients, following proprietary patterns. MsAccess is not a spatial database on its own (it does not provide a spatial data model, so obviously no spatial data loading capabilities, spatial indexing or extended spatial SQL), so ESRI manages spatial information within a standard BLOB attribute. You would not be able to access such a spatial information from outside of ArcGIS environment, as it would be the case for other spatial databases not managed through any middle tier (i.e. ArcSDE), as Oracle (including free entry point Oracle XE, available also for commercial use) and Open Source PostgreSQL/PostGIS (the latter version of PostGIS, 2.0, supporting integrated raster and vector data model).
A previous reply pointed attention to the 2Gb limit, while I would also stress how the ESRI file geodatabase model looks like more flexible and not affected by previous limit.
Considering that most of your system users would not have access to ArcGIS licenses, I understand the reasons why you pointed attention at MsOffice applications; however I would not recommend to edit your MsAccess geodatabase outside of ESRI environment, namely ArcCatalog or ArcMap.
You should consider the option of a traditional dual architecture, alphanumeric attributes being managed in the databases clearly distinct from geographic information managed within the GIS environment. It is an old fashioned architecture, I do not like it too much. However if you would still want to explore the option, you could store spatio-temporal coordinates as attributes, but you would obviously be confined to simple point geometries and you would still lack spatial reference system and any related geographic metadata.
A much better solution, particularly if you consider multi-user concurrent access, would be to focus on native spatial databases. Since ArcGIS 10.0, direct access is supported through query layers: once you connect to a spatial database, you can define a (spatial) query and use the resulting layer in the table of contents as any other layers. Such an option would empower you with the flexibility of fully SQL standard compliant databases and the possibility to access the spatial information also through geographic clients other than ESRI (i.e. QuantumGIS, which is natively coupled with PostGIS).
Depending upon license levels, query layers would be in read-only mode, which is an issue you should probably consider with care.