Does it make sense to use a compute shader with Dispatch(1,1,1) and Numthreads[1,1,1] to draw a cone?

There may at times be reasons to use a compute shader with Dispatch(1, 1,1) and Numthreads[1,1,1], but drawing a cone is not the use case for that.

By limiting your compute shader to a single thread, you're giving up the parallel computation benefits you could be getting from the GPU. We could draw potentially every pixel of the cone in parallel, rather than looping over the cone one step at a time serially. This parallelism minimizes the total latency from when we start drawing the cone to when we're done, and scales much better to use the hardware's many cores to handle different numbers of pixels that need to be drawn.

Myself, I'd skip using a compute shader entirely. You can achieve this effect with a plain vanilla vertex-fragment shader and no loops at all (and the cone is fully solid, without the moiré stripes of skipped pixels seen in the question):

We'll start by building a mesh that represents a bounding volume for your cone - something that will cover every fragment of the screen you want your cone to occupy, though it's OK if it covers a bit more. We'll draw this bounding mesh with a shader that draws the cone contained inside, and clips-out any excess space outside.

For my example, I'm using a standard 1-unit-wide cube mesh, with vertices at (±0.5, ±0.5, ±0.5). To be more efficient, your bounds could be a low-poly cone, so you don't need to clip as much empty space.

We'll render this mesh flipped inside-out, so we're drawing its far faces instead of the nearer ones. This means even if the camera moves up to/inside the bounding volume, it'll still see the far face, so our shader will still run there (rather than seeing a hole in our cone where the bounding volume clips the near plane).

In the vertex shader, we'll save the position of "this" vertex and the eye vector (pointing from the vertex to the camera), both in object-local space. Those will be interpolated and passed to the fragment shader, to become the initial position and direction of a ray we'll "trace" through the bounding volume, to find where it intersects the cone.

In my case, I'll shift the z coordinate in the shader so it runs 0...1, putting the point of the cone (z=0) at one face of the bounding cube.

struct v2f {
    float4 vertex : SV_POSITION;
    float3 pos : TEXCOORD0;
    float depth: TEXCOORD1;
    float3 dir : TEXCOORD2;
};

v2f vert (appdata v) {
    v2f o;

    // Project vertex to clip space, as normal.
    o.vertex = mul(MVP, v.vertex);

    // Save depth separately to use in fragment shader.
    o.depth - o.vertex.w;
    
    // Save local position of vertex to interpolate.
    o.pos = v.vertex.xyz;
    o.pos.z += 0.5f; // HACK: remapping cube to 0...1 on the Z
    // (Because I was too lazy to make a custom model)

    // Get vector from vertex to camera, also in local space.
    o.dir = mul(WorldToObject, float4(CameraPos, 1)).xyz - v.vertex.xyz;

    return o;
}

Then in the fragment shader, we can analytically compute where this ray intersects the cone (without raymarching one step at a time), and return the "outside" face that should be seen by the camera.

struct fragout {
    fixed4 colour : SV_Target;
    float depth : SV_Depth;
};

float eye_to_nonlinear_depth(float depth) {
    // Using Unity convention:
    // _ZBufferParams.z = (1 - far)/(near * far) 
    //                    (or -1 times that if using reverse Z buffer)
    // _ZBufferParams.w = 1 / near 
    //                    (or 1/far if using reverse Z buffer)

    return (1.0 - (depth * _ZBufferParams.w)) 
           / (depth * _ZBufferParams.z);
}

fragout frag (v2f i) {
    fragout o;

    // Coefficients for quadratic formula:
    float a = dot(i.dir.xy, i.dir.xy) - 0.25f * i.dir.z * i.dir.z;
    float b = 2 * dot(i.pos.xy, i.dir.xy) - 0.5f * i.pos.z * i.dir.z;
    float c = dot(i.pos.xy, i.pos.xy) - 0.25f * i.pos.z * i.pos.z;

    // Discriminant - if less than zero, we missed the cone entirely.
    float disc = b*b - 4 * a * c;
    clip(disc);
    float step = sqrt(disc);

    // Parameter value t where we cross the cone.
    float t = (-b + step)/(2*a);

    // Flip which side we're looking at if outside the bounds.
    if (t < 0 || i.pos.z + i.dir.z * t > 1) {
        t -= step/a;
    }
    
    // Reconstruct local position on cone surface.
    float3 intersect = i.pos + t * i.dir;

    // If outside of bounds, clip it out.
    clip(intersect.z * (1-intersect.z));

    // For debug purposes, display local intersection point as a colour.
    o.colour = fixed4(intersect, 1.0f);
    o.colour.rg *= 2.0f;

    // t = 0 means we're at the original depth interpolated from the vertices.
    // t = 1 means we've travelled the full eye vector and hit the camera.
    // So we can just scale the original depth by 1-t and remap it:
    o.depth = eye_to_nonlinear_depth(i.depth * (1.0f - t));

    return o;
}

Because we're using the object's (inverse) model matrix, we can rotate and scale the cone just by orienting and scaling the model:

And because we calculate the eye depth of the intersection, it Z-sorts correctly with other geometry:

This version draws the cone as though it's hollow, but if you want to cap it off, or draw it translucent so you see both faces, or even vary its opacity by how much of the cone's solid volume the view ray cuts through, any of those are doable too with just some tweaks to the math.

Once you know what part of the cone your view ray is hitting, you can shade it any way you like - you're not limited to the debug colours I've used here.