Marc-Andre Lemburg noted:

  BTW: The API PyUnicode_AsString() is pretty useless by itself - there's
  no way to access the size information of the returned string without
  again going to the Unicode object.
  
  I'd suggest to remove the API altogether and not only deprecating it.
  
  Furthermore, the API PyUnicode_AsStringAndSize() does not follow the API
  signature of PyString_AsStringAndSize() in that it passes back the
  pointer to the string as output parameter. That should be changed as
  well. Note that PyString_AsStringAndSize() already does this for both
  8-bit strings and Unicode, so the special Unicode API is not really
  needed at all or you may want to rename PyString_AsStringAndSize() to
  PyUnicode_AsStringAndSize().
  
  Finally, since there are many cases where the string buffer contents are
  copied to a new buffer, it's probably worthwhile to add a new API which
  does the copying straight away and also deals with the overflow cases in
  a central place. I'd suggest PyUnicode_AsChar() (with an API like
  PyUnicode_AsWideChar()).

Honestly, I am not sure if removing PyUnicode_AsString() is a good idea.
There is many cases where the size of the returned string is not needed.
Furthermore, this would be a rather major backward-incompatible change
to be included in a beta release.

Oops, it seems Marc-André has already opened an issue about this.

Closing as duplicate.