1: If it's truly turn based, this should be completely fine, and will make life a lot easier I'd say. I've even considering using compressed json strings for packets on real time games just because JSON rocks.
I struggled with this at first but found the data driven architecture to be quite nice. I have the basic Object class which you can attach any number of different types of attributes too. These include mesh/materials, variables, lights, particle systems, rigid bodies, etc. Attributes are user create-able too so you can attach any number of your own attribute types to the object. These can be used and manipulated in the specific game code, outside of the engine. One other thing you can do is attach a lua script to an object which has the ability to manipulate the object directly. Obviously some things need coded specific to the game itself, but most things can be accomplished with a flexible attribute system. I know this still sounds like a tangle web, but I invite you to just try coding a simple prototype... I think you'll find it easy to get through once you start. My code is on github, feel free to take a look. Here's a starting point: https://github.com/palodequeso/Element-Games-Engine/blob/master/Engine/Game/ObjectAttribute.h
Well, it depends on what kind of system configurations you want to support. Do your research and make sure that it's supported on devices that you are targeting. Also, make sure that it is giving you adequate performance for your application. Besides that it's up to you! I encourage you to do the research and try it out. That's half the fun! If you are using opengl or directx, there are definitely performance measurement tools. I will say that in a deferred pipeline it's not uncommon to have 32bits per channel to store gbuffer data, so why not store high resolution normals, I do, it works out pretty great!
I too am interested in a good resource for this, although I think I have a good idea of how to acheive it. Currently I am only using a simple radius check in the frag. However, since doing 3d picking I think I've realized a different approach. If you take the view_matrix (camera_matrix) and the projection_matrix and find the corners of affect like this:
You then know the bounds for the rectangle by using x, y, of each corner and can define a scissor rectangle. Although I'm sure there's a much better way to do this, and I haven't yet tested this. Just figured I'd give you some inspiration to get the wheels turning.