Use FILE_MAX from BLI_path_util.h

For future code, use the functionality in PIL_time.h and PIL_time_utildefines.h.

You can only refer to "the" pre-defined vertex list if the reader already knows about this list. This comment also doesn't mean anything, because any list of vertex indices corresponds to some list of vertices.

Are these the vertices of the evaluated mesh?

Try to write full English sentences; this sentence is missing a verb. I would write something like this:

Assumes memory for data_to_export->mvert is already allocated. See get_transformed_mesh_vertices().

The assumption that memory has been allocated has little to do with where that allocation happens exactly. It's better to describe this in two sentences instead of trying to put as much info as possible into a single one.

Then again, I think it's not that nice design that the get_transformed_...() functions have different semantics. One allocates the required memory, the other one doesn't, and now there is an inter-dependency between them. I would probably write a third function that allocates the memory, then calls the other two.

You can make ob_eval const.

Everything that exists is pre-defined, as it happened before this function is called. Also "get_...." functions should get/return something, and "store_..." functions should store something. Now the comment says one thing but the function name says something else.

This function seems to convert from mesh loops to poligon vertices. This is I think more important than the fact that the vertices are stored by index. This may give some ideas for a better function name.

Don't use single-letter variables. poly_index is much more readable than i, and loop_index more readable than j'.

Don't re-index the same list three times in this loop. Use a variable like

Polygon & polygon = data_to_export->polygon_list[i];

This is probably to be able to benchmark either one or the other. Add that to a comment so that this is explicit. Same with the functions below.

What is an "axis component"? And isn't there already functionality in Blender that computes face normals?

The MALWAYS_INLINE macro is defined in BLI_math_inline.h, so you have to #include that file too. Don't rely on other header files to include this file for you, always include what you need.

Everything is "data"; what would be the difference between "write_obj" and "write_obj_data"?

Declare data_to_export as const.

Mention the file path in error messages, or things will be hell to debug later when you try to export 10000 OBJ files and one of them fails.

Don't hard-code Blender's version number. Use BKE_blender_version.h.

Don't append trailing whitespace (i.e. the space before the \n).

There is no need to document here that the first two characters are the ID code; that's global for Blender.

What is the reason to use a pointer here, instead of a reference? You're already doing that for polygons. below.

Declare vertex as const.

face_normal_axis_component() iterates over all the vertices of the face, and computes the normal. This should not be done three times. Just compute the normal once, store it as a float[3], then write it.