Okay, it seems this is much more complicated than I expected. After talking with the EEVEE & Viewport people, it seems that it's quite important that the evaluation happens on the GPU rather than the CPU.
Of course we probably still need CPU evaluation for various algorithms implemented on the CPU, but apparently the GPU evaluation is important since uploading attribute data to the GPU has a significant performance impact.

• Currently accelerated drawing is supported for Catmull Rom curves, though apparently it is only hooked up to the old particle system, not the new object type.
• Support for Bezier curves, poly curves, and NURBS curves still needs implementing.
• Support for generic attributes on curves is a known TODO in drawing code.
• Grouping/batching curves by their length (number of control points) might be important. Batching by curve type may or may not be helpful.
• Support for cyclic curves should also be implemented.

For Cycles, at least it's in an "initially functional" state. But many of the same TODOs apply, including support for other curve types, and cyclic curves.

The next steps seem to be:

• Split the drawing code for the new curves object from the old particle system. At least splitting the batch cache generation is obvious, probably the shaders also.
• Proper support for drawing curves with different lengths (don't resample them all to the same length before drawing).
• Implement support for different curve types, basically porting some of the code from curve_bezier.cc, curve_catmull_rom.cc, and curve_nurbs.cc to a compute shader.

Notes from a discussion earlier today:

• Varying segment count
  • The conversion to triangles by the render engine relies on the fact that there are the same number of segments in each curve
  • This may work for hair, but it doesn't work for curves, since the use case is more general
  • Evaluating curves with the same number of segments in batches, and adding padding at the end where necessary should work.
    • The padding points can be added at the same position as the last point for each curve
  • Since all curves potentially have a unique segment count, grouping curves with similar point counts together makes sense.
    • All curves with less than 4 points, less than 8, less than 16, etc.
• Curve types
  • The render engine (i.e. EEVEE/Workbench) just gets a buffer of the final evaluated points, so it doesn't matter how they are generated.
  • Each curve type could have a separate shader, though some of the shader code could be shared.
  • Goal is to support evaluating Bezier curves and Catmull Rom curves on the GPU, and support drawing poly curves. NURBS curves can be evaluated on the CPU for now.