It will be different depending on whether s2 is enabled or not. To be sure I would use a map projection (local laea: Lambert Azimuthal Equal Area) (for each individual feature, if their coverage is "large enough", fine for something less than continent-size at a layer level) or use s2 (spherical approximating cells) or an ellipsoidal buffering wrapper more directly. You are supposed to blat the crs metadata if you want buffers in longlat for longlat data in sf, but it won't give real geographic distances for many projections that don't support that) and note that terra is very different - it will always use ellipsoidal methods no matter what crs is in use - but has its own vagaries here). It's largely why I don't use these tools for this kind of question, I like functions that do exactly what they say. Doing metrics in geographic space is what map projections exist for and recent attempts to hide this problem from users injects much uncertainty and new problems that are hard to track.
the units on the various parts of the CRS is completely different to what sf does with the units package and with its own logic to choose math- vs spherical- vs ellipsoidal- distance, the crs unit for longlat (EPSG:4326) is definitely degrees (it could be radians or microdegrees but that never happens in practice), and the LENGTHUNIT on the crs wkt refers to the radius of the ellipsoid that the longlat/degrees crs is based on (so the "units_gdal" does impact what sf chooses to do, but the LENGTHUNIT does not) - if the units_gdal was "US Foot" then