See discussion at #983 (comment), repeating my summary here:

In general: yes, there is a slowdown for methods/properties of scalar Geometry objects.
For some things (like the constructors of the different geometry classes), we can optimize this by spending some effort in having an efficient single-geometry version (this can probably be done in the class constructor itself, eg by using pygeos.lib.points instead of pygeos.points).
But for the bulk of the ufuncs (the spatial predicates, operations, etc., i.e. those that directly wrap one of the GEOS<..op..>_r functions), this is the consequence of having general ufunc (array-aware) functions. This ufunc machinery will always have some overhead, and for single geometries this overhead can be noticeable (and seems to be larger as the benefit from not using ctypes).

So I think that generally speaking we can live with a small additional overhead (given that the vectorized operations will be much faster), but we should of course still fix the slowdown where easily possible.