ArcPy is a Python extension module. It includes several orders of magnitude more functionality than the FGDB API. Even if you only consider file geodatabase access, ArcPy supports significantly more functionality.
The FGDB API is just a C++ library. You can't just use a C++ API in Python, you'd need to come up with a design and write an extension to implement that design before you could use it from Python. You could do it, but it isn't likely to be a trivial exercise.
...Even if you only consider file geodatabase access, ArcPy supports significantly more functionality.
Not true by a long shot. The FGDB API has far more functionality than you know. It does a ton of things and it does it at a lower level which is exactly what I need.
The FGDB API is just a C++ library... You could do it, but it isn't likely to be a trivial exercise.
Yep, I'm aware of that. But what I was looking for was a resource like the OGR library, which is a Python wrapper for the FGDB API. And it works for ArcSDE and a host of other spatial data formats. http://trac.osgeo.org/gdal/wiki/GdalOgrInPython
OGR will work fine with the File GDB, just build against the API and you'll have a FGDB driver from within GDAL/OGR and its SWIG Python bindings.
If you're working with features, you can also use Sean Gilles' Pythonic wrapper for OGR, Fiona. And as Vince mentioned, you can use SWIG to create a wrapper to the API as it's just C++, there's also an idea for this if you think it should be something that Esri supports. That said, for many use-cases GDAL/OGR works well directly.
Great article. Thanks for sharing. I ultimately used the C# api because I was able to wrap it as a gp tool. But this topic is one I always wanted to come back to. You've given me a good reason to do so. How is performance with bulk loads; do you happen to know?