OBJ files are one of the simplest 3D file formats to parse, but the are pretty basic in what they can hold as well. When I read OBJs, I read the entire file at once. Then I scan through all the lines, and check the first letters of each. Add up all the lines that begin with "v " and you have your vertex count. Add up all the lines that being with "vn " and you have your normal count. Add up all the lines that begin with "vt " and you have your texture coord count. Likewise with "f " and the face count. Then you can pre-allocate your arrays, go back to the beginning of the buffer, and actually parse the data into your arrays.
OBJ files don't contain any sort of heirarchy info or pivot information. But that should actually be part of your rig, not your geometry. OBJs also have very basic material support; the "usemtl" line signals that all the following faces should use the named material until you come across another usemtl line. The actual material specification is stored in a separate .mat file per obj, and it is pretty simple/restricted as well. But there's no reason your engine can't use a .mat file in its own format, and still use the OBJ exporter from your 3D package.
I don't know about Blender, but Maya's OBJ importer/exporter really kinda sucks. I wrote my own OBJ plugin for Maya for importing/exporting, which could then be modified/expanded to export something specific to an engine should I need it. But OBJ files are a good standard to start with to make sure everything is working correctly.
Cheers,
Michael