Hey everybody, still no solution  Zakwayda is right, as much as I tested with a Blender model, I'm sure there's something wrong with my implementation. I've actually uploaded the entire engine to github. Hopefully it's not too large of a project. 

[GitHub link]

I'll leave a little guide here so nobody has to guess where everything is. By the way, if you want to run the project, you can either host the client folder or if you got node installed:

$ npm install
// after dependency download
$ node server

If you're using nodejs, the game will be served at localhost:8080.

By the way, I tried drawing the scene with no mipmapping but got the following warning: 

texture bound to texture unit 2 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.

Which is true, my planet texture is w > h. I tried it with mipmapping off, min and mag filters on nearest.

Guide

If you press the lockmouse button,  you enter fps mode enabling you to  navigate around using your mouse and arrow keys (not WASD).

CORE

1. src/engine/loop.js: Game Loop. Physics and Render loops called from here

MAIN ENTRY

1. src/main.js: This is where I create the planet entities, textures, meshes. 
   • Game.load:  calls a function in src/game/loader.js and loads all objs, images, etc.
   • Game.ready: (line26) is called once all assets are ready and before the game starts

UV SPHERE, RENDERING, MESH AND TEXTURE CONSTRUCTORS

1. src/engine/systems/drawscene.js: (line 109) Entities are rendered here.
2. src/engine/texture/texture.js: The Texture object for creating new Textures 
3. src/engine/data/model.js: (line 216) The UV Sphere function is located here, it's the very last static function.
4. src/engine/data/mesh.js: This is the Mesh object for new Meshes 

SHADER

1. src/shaders/phong.frag: The only shader I'm using aside from the post processing ones. You'll notice I'm feeding vec4 color the diffuse texture map only, ignoring my lighting algorithm for now.

MATH

1. src/engine/math: Here you'll find matrices, vectors and also a class for calculating normals.  

I took a look at the project. I think the culprit may be this in your fragment function:

vec2 uvs =  fract(uvcoords).xy * uvtile;

If you remove the fract() call, the artifacts disappear (for me anyway).

I haven't dug deep enough to tell you exactly why that's causing the artifacts you're seeing, but if I figure it out I'll post back.

So it may be, as you suggested initially based on comparison with Blender, that the mesh itself (at least the vertex positions) isn't the culprit. However, it does look to me like the vertex positions aren't welded at the seam and at the poles. (Maybe they are, but I didn't see it in the code.) I'm not seeing any problems because of this, but in principle at least this can lead to 'sparklies' or similar artifacts (which you may already know). In any case, regardless of whether it's an issue, I'd weld the sphere vertices if they're not already.

2 hours ago, Zakwayda said:

I took a look at the project. I think the culprit may be this in your fragment function:

vec2 uvs =  fract(uvcoords).xy * uvtile;

If you remove the fract() call, the artifacts disappear (for me anyway).

I haven't dug deep enough to tell you exactly why that's causing the artifacts you're seeing, but if I figure it out I'll post back.

So it may be, as you suggested initially based on comparison with Blender, that the mesh itself (at least the vertex positions) isn't the culprit. However, it does look to me like the vertex positions aren't welded at the seam and at the poles. (Maybe they are, but I didn't see it in the code.) I'm not seeing any problems because of this, but in principle at least this can lead to 'sparklies' or similar artifacts (which you may already know). In any case, regardless of whether it's an issue, I'd weld the sphere vertices if they're not already.

Thank you so much! Removing the fract function was exactly the solution! Why was this occurring though? Could it be due to the welding issue, or maybe floating point precision? I'll figure out another way to dynamically tile textures. 

I appreciate all the answers suggested, thanks all. 

Update: 

Hodgeman's answer above explains why this is happening for those of you wondering.

17 minutes ago, Hashbrown said:

Could it be due to the welding issue

Welding is something that's done inside your 3d modelling application, but once it's in the 3d engine it's just a list of verts.  All welding does is make verts in the UV space stick together to make it easier to work with.  Once it's rendered everything is disconnected, faces aren't even connected anymore let alone UV stuff.

As for why exactly that's happening, I'm not exactly sure.  All that's doing is making sure the UV coodinates for the fragment are clamped to 0..1.  However, as was pointed out, that's what the texture sampler parameters like clamp and wrap already do, so there's no need for it.

49 minutes ago, gaxio said:

Welding is something that's done inside your 3d modelling application, but once it's in the 3d engine it's just a list of verts.  All welding does is make verts in the UV space stick together to make it easier to work with.  Once it's rendered everything is disconnected, faces aren't even connected anymore let alone UV stuff.

I think the OP is generating the mesh procedurally in code rather than importing it. What I was referring to was vertex positions that should be coincident, but differ due to numerical error. I think there may be some cases of this in the OP's mesh (although it doesn't seem to be causing any artifacts).