Which brings better performance at run-time: a cube imported from a mesh, or a cube made from hardcoded vertices?
Are there limitations to a certain method? Is one of them better architectural-wise?
Once it's in memory, verts are verts.
If by hardcoded vertices, you mean glBegin ... glEnd (OpenGL), or Draw(Indexed)PrimitiveUP (Direct3D), these methods are inferior because they result in the vertices being transferred from system memory to the graphics card every time they're called.
If, however, you're putting your vertices into a vertex buffer like you should be, it really doesn't matter. If your cube is logically an art asset, like the Horadric Cube, or the Weighted Companion Cube, it should probably be stored as a model on disk. If your cube is, on the other hand, intended to be used for skybox rendering, and therefore immutable, hard-coding it is probably fine.
When it comes down to raw speed, a hard-coded set of vertices (and indices) embedded in the application's data region will be faster; this is because you avoid the cost of loading the mesh from disk. For simple applications, such as rendering a triangle or a cube on the screen, this approach is fine. In practice however, geometry and other resources such as textures are typically loaded from some resource file on disk into memory. This approach is beneficial for many reasons, but two major reasons are: loading and unloading resources at will and decoupling the application from its resources.
Depends. If we're talking something as simple as a cube, you're going to want to hardcode it. The loading time for all 8 vertices is not worth it. Same can be said for any simple geometric shape; just make a CreateSphereMesh, CreateCubeMesh, etc. set of functions.
However, have fun making an OVER 9000 vertex model by specifying the individual vertices. And tweaking. Oh, and animating. That's when it's much better to have it as a model format.