I am going to attack your question out of order, partly because I am seeing issues with the way I think your attacking the problem.
This [cubes] would certainly be easy as then I could ray cast against them - but I've tried this and rendering that many cubes slows down the game a lot!
I don't know why this would be slow, unless you are constantly creating, altering, and destroying these cubes at run-time, but even then 200 cubes is child's play to unity (when you start getting to say 10,000 simultaneously interacting items then Unity can start to have problems.
You don't need to have physical "objects" in your world to ray-cast between them. you simply need to have objects in your world (Empty GameObjects)
I suppose my question is - is it unnecessarily expensive to have a load of cubes set up like this, but not rendered? Or should the cost of having a load of cube shaped collision volumes be only marginally more expensive than emulating this in code? (if at all...)
200 cubes (even 200 RigidBodies) is not that much in Unity. on the part about emulating in code depends on what you absolutely need your nodes to know.
Also as a side question - should I be able to render say, 200 cubes and have a smooth game? Am I missing some instancing options? I presumed things would be automatically instanced.
instancing in Unity is based around the prefab system (basically make up your thing then create a prefab, and then use it again, and again in your game/scenes)
At first I was going to emulate a grid system by capturing touches / mouse clicks and rounding the coordinates to the nearest whole numbers. This is very low cost and works well for placing things, however I'm a bit of an AI geek and I've decided to make a more tangible grid so that the agents can run searches on it for pathfinding.
if you can mask your entire game level/scene in a fixed grid you should in theory be able to use standard grid traversal, but all of your book keeping will probably need to be specificly value centric, and in the end run this is not going to be very clean/efficient.
For this I'll need a grid of nodes and for those nodes to have a bit of information attached. Would it be a much better idea to do this entirely in code?
yes, no, maybe it depends on what information you absolutely need your nodes to have (the simplest node I can think of for a tower defense game is is a point, a bool occupied, and a bool reachable)
Or could I get away with placing actual cubes in a big grid on the map?
Why would you do this? I see no value besides having something that you can physically see in the editor, and when it comes time to run the game you wont be doing anything with these cudes as cubes, so why have them in the first place if your just going to take away their collision, and rendering. All you have left is a transform which you could have right away by having empty gameObjects.
the easiest way to do nodes in Unity is to create empty gameObjects(mainly for the position), and then give them a script for all the variables you need, and then put all those nodes onto their own layer.