"Added and removed frequently" really is not that frequent in most games of the genre. Bursts of mining activity are interspersed among long bouts of exploration, farming, chatting, fighting, etc.
That said, the difference mostly comes down to performance. Which is best is entirely dependent on your API of choice, target OS, target hardware, and specific game. The best answer is to just implement whichever you find simplest to develop and then - if and only if you have performance problems - implement the other approach and compare the results.
The primary advantage of instancing is that it greatly reduces the amount of data you have to send over the bus and reduces the amount of host work you have to do. Adding or removing a block can be as simple as removing an item from an array (rather than regenerating a whole mesh), and the array need only be a texture index and a position (compared to the other approach which needs 12 triangle positions, uv coords, and texture positions per free-floating cube).
The primary advantage of building a mesh is that it allows more potential optimization and reduces the complexity of shaders somewhat. Obscured cube faces can be culled from the generated mesh much more easily than with instancing (as the data is available almost for free while building the mesh), which can greatly reduce bandwidth required (maybe even further than using instancing), reduces the number of triangles the rasterizer must rasterize, and reduces overdraw and fillrate consumption.
Note that you can do the second approach with even more smarts. If you're worried about frequent changes, just remember the "bursty" activity (if it applies to your game). You can generate a less efficient but easier to modify mesh after an edit and then lazily generate a more compact mesh after a second or three of inactivity. You could even switch to instancing when edits are happening and revert to meshes afterward. With a chunk-based world, you can do this on a per-chunk basis; thus if the mesh generation approach is faster, you let distant chunks keep their efficient meshes and only the current chunk need use a slower rendering method.
Also note that instancing is not available on all modern hardware. Probably not an issue for an XNA game, but if you plan to port to mobile OSes (maybe using MonoGame), remember that most devices are still using OpenGL ES 2.0 which does not support instancing. GLES3 devices are slowly making their way to market on some newer devices, though it'll be years before you'll want to stop caring about today's devices. WebGL is also based on GLES2 and there's been little official traction on a WebGL2 that offers GLES3-level functionality. GLES2 may be a historical relic by the time your game is even released, if you're lucky, or it may still be a limiting factor for your target markets.