Since you simply want to map a predefined set of geometries - your fins - to a quad grid, you could change your entire strategy to a more abstracted and fast one!
Each fin has 8 neighbouring fins, except for the boundary grid cells, where there are less. The neighbours on the left and right, as well as the diagonal neighbours don’t really have a stake in this example, since fins only seem to be able to intersect in forward and backward direction. Consequently, you already don’t have to all other neighbours.
Now, for each geometry you construct a set of rules, meaning which type of other fin can be placed on the grid cell before and after the concerned fin. A simple list of indices to chose from would suffice here.
Having all the geometries and rules, you now start for instance at the first grid cell, place whatever fin, since all forward grid cells are empty and the backwards ones don’t exist (are out of bounds). This will be the case for the entire first row.
Starting from the second row of grid cells you now need to take into account the neighbour in the row before and only choose from compatible cells to this one, and so fourth.
You might see a pattern emerging here. Note that if you traverse your grid row by row starting from the first one, you only ever need to check the neighbour in the row before the current grid cell. This means that you really only need to define rules for which fins can be placed in front of another fin.
However, if you want to populate the grid at random locations, you need to construct rules for the front and back.
With this strategy there is no need for checking brep intersections - which is a costly operation and prone to be unstable -, and since you have quite big grid, it should also be much faster than your current definition.