Depending on the intended behaviors and gameplay implications, having any FSMs in my experience on the individual tiles is going to hurt framerate. On my tiles I wanted to be able to have a "selected" textures so when you click on them, it turns it to another color, the way I accomplished this was having an FSM on the tile, that would change the color, then deactivate itself (It was a child object of the tile gameobject). When I wanted to change the color, I'd find the object, turn on the color controller game object, send a command to change the color, and it would turn itself off again automatically.
As far as finding the neighbor state, another approach I took for mine was to at the same time as creating the geometry array, I also created an INT array of state ID's. So when it was spawning A1, B1, etc it would also add a 1 to that same ID number on a different array. So if you were trying to find if the tile next to object was activated or not, you'd check the state number (by finding closet game object to your box position plus 1 to the appropriate float value). Then getting that index id and checking it against the state). If that makes sense. So if I was writing an FSM I'd, get my position, save to floats, add 1 to appropriate direction, get nearest object from an array, get position of object, float compare to ensure it's in the exact coordinates, if so, check the state from my state array, something like that. If you'd just want to see if theres a block there, you could forgo states entirely and do just that part minus states.