Using random unstructured dense data as a proxy isn’t very useful. Real problems have sparse structure, and solvers are built to exploit that.
Going via the C API is probably a little faster, but you’ll still have the same issue. You can’t pass a dense matrix to Gurobi, you have to pass the row and column indices, as well as a vector of data. So you end up passing a a few 5e7 length vectors, and the data structures and algorithms inside Gurobi assume sparsity.
For most realistic problems, the cost of building the JuMP model is (much) less than the cost of solving it, so if you’re struggling to build it, Gurobi will likely struggle to solve it.
You also have to factor in the time it takes you to write the C API version, as well as the likelihood of bugs etc 
. In general, you should probably just use JuMP, and only once all else fails should you consider alternatives.