> scientific projects that depend on it may lag longer as rebuilds and releases will need to happen on PyPI, conda, and conda-forge.

Keep in mind that binary artifacts (wheels, Conda/distro packages) should not be affected. They need to be re-built for Python 3.8 *either way*, because the ABI changed.

The only artifacts that putting tp_print back in helps are sdists that include pre-generated Cython output, plus possibly projects that pin Cython to an older version.

Specifically, for any platform without a C compiler installed, users aren't helped by putting tp_print back in.

So:

(1) Status-quo (keep everything as is in 3.8b1):
  - binary/compiled distributions need to be re-built (*1)
  - sdists need to be re-generated with an up-to-date Cython (*2)
  - projects that pin Cython need to update it.
  + pure source distributions (where compiling involves running Cython) works as before (*3)
  + type objects do not waste memory
  + Cython can implement vectorcall optimizations for past Python versions (before 3.8)

(2) Apply PR 14193:
  - binary/compiled distributions still need to be re-built (*1)
  + sdists DO NOT need to be re-generated (*2)
  + projects that pin Cython DO NOT need to update it.
  + pure source distributions (where compiling involves running Cython) works as before (*3)
  - type objects get 8 bytes larger
  + Cython can implement vectorcall optimizations for past Python versions (before 3.8)

(3) Put back tp_print the way it was in 3.7:
  - binary/compiled distributions still need to be re-built (*1)
  + sdists DO NOT need to be re-generated (*2)
  + projects that pin Cython DO NOT need to update it.
  + pure source distributions (where compiling involves running Cython) works as before (*3)
  - type objects get 8 bytes larger
  - Cython can NOT implement vectorcall optimizations for past (pre-3.8) Python versions

*1: applicable to most wheel consumers, conda users, etc.
*2: applicable to sdist consumers with a compiler
*3: should be applicable to Conda/Fedora/Debian/... packagers (not so much end users)

> Is four months really an unreasonable timeline? I thought most of these packages released more frequently than CPython.

Note that maintainers of these packages need to take an action (build wheels) anyway to support Python 3.8 (on compiler-less platforms). They need to test, and ideally even read "Porting to Python 3.8" and adjust the code.
Is re-generating Cython output, and bumping the version, too much of an *added* burden here?

If a project doesn't release 3.8 wheels by Python 3.8.0rc1, we don't get feedback on it from PyPI users (but Conda & Linux distros should be unaffected, if they run Cython on build).