Draw calls by themselves are not always the bottleneck, it is what happens between them that is. Generally when you issue a draw call, the command buffer (state changes, data uploads, etc.) is evaluated and the expense of changing many states is actually deferred until this point. For instance, if you issue the same draw call back-to-back the second draw call will be significantly less expensive since there are no state changes. Because of this it is difficult to definitively say "keep your draw call count below X."
The story has traditionally been different in Direct3D, where pre-Windows Vista draw calls invoked a user-mode to kernel-mode context switch. Before D3D had a user-mode front-end (Windows Vista+) every draw call would cause an expensive context switch in addition to the expense of deferred state setup. When people optimize to minimize draw calls, this is probably why.
It is more effective to minimize state changes, which usually has a side-effect of reducing draw calls too. You'll want to develop a batch processor that sorts your geometry to minimize state changes - generally textures are the most important state change to minimize.
If you are seeing a lot of errors in gDEBugger, you may want to run your Windows software in an OpenGL debug context and enable debug output. This is an OpenGL 4.x-era feature, but if your driver supports the OpenGL ES extension it almost certainly has ARB_debug_output as well. Debug output will warn you when you do things like use misaligned data structures, which is handy for performance testing. See this answer for more details.