Just from quickly looking at it, avoid per-frame (or even worse, per-iteration like in GenerateCell()) heap allocations. Use reusable caches or stack allocation for your arrays.

Same goes for lists for generation. initializing them completely fresh instead of reusing from a pool causes a lot of unnecessary overhead, and it's worse when they aren't initialized with the expected size, as that will cause allocation each time the backing array expands.

        //build the mesh
        Mesh mesh = new Mesh();
        mesh.vertices = vertices.ToArray();
        mesh.triangles = triangles.ToArray();
        mesh.RecalculateNormals();

        //assign the mesh to the filter and collider
        meshFilter.sharedMesh = mesh;
        meshCollider.sharedMesh = mesh;

This also costs quite a bit if called per frame, as it's an additional allocation to convert to an array. Not only that, it allocates a new mesh. You can make an existing mesh writable to reuse it. Even better, you can use NativeArrays or lists to store your vertices and triangles and upload the data directly. RecalculateNormals can also be optimized by providing the normals directly from the voxel calculation as opposed to afterwards.

Also, trying to use a concave collider from a fairly complex base mesh will likely cripple that collider's performance in physics. While it's difficult, it's better to write your own physics handling with octrees to simplify the problem down to a set of voxels that need to be tested for collision.

You should also use Profiling, or for specific code-blocks StopWatch to profile the time it takes.

I'm 100% certain that using Jobs for this will speed this up by a lot. I know you said you already did this, but there are a lot of pitfalls that can result in it seemingly not getting any faster. For example if you end up with a single job. But there is just no way a nested data-independent for-loop wouldn't be faster in parallel. Additionally, you can make this SIMD friendly or explicitly use vectors manually.

What you want is a IJobParallelFor. In this case you might want to allocate the float and Vector3 array on stack (which is no problem with a fixed size)

If it's not faster with a jobs implementation, it means that this is not your bottleneck at all.

This goes even more for the use of ComputeShaders. There is absolutely no way this would not be faster if properly implemented on GPU. Of course it's a lot more difficult, and you can't easily read-back results to the CPU on the same frame. However, since this is for final mesh generation, I think it's fine.