A clean room design is a preventative defence strategy in anticipation of copyright infringement claims. The idea is that a new creative work cannot infringe on the copyright of an earlier work if the new work's authors did not view the earlier work. A clean room design process implements this isolation by having different people handle reverse-engineering of the earlier work and creating the new work, with the two groups only communicating via a spec that can be more easily reviewed for non-infringement. If the two works have any similarities that would otherwise look like infringement, this process demonstrates that those similarities might merely be a consequence of the nature of the problem, and not a copied creative expression.
Because it is a preventative defence strategy, the value of clean room design manifests itself only when someone claims infringement against you. If that is unlikely to ever happen, you might feel comfortable with a bit of risk without taking further steps to mitigate it. Note that even with a clean room process, you can never entirely eliminate the risk of being sued for infringement and the risk of losing such a trial.
If you already have some kind of specification then sure, you can work from that. However, your claim that documentation of the earlier work may represent a non-infringing specification for the earlier work is highly dubious:
Several people have written documentation for this code, summarizing what it does. […] So in this case the docs written by prior ports are the specification. I assert that for this particular case the docs can clearly not contain copyright material (because they only refer what the existing code does, not how it does it), so the lawyer step can be skipped
The first problem is that there is a potential chain of infringement here. From the earlier work other (potentially infringing) ports were written, from which (potentially still infringing) documentation was created, on which you would base your reimplementation. It is entirely feasible that the other ports are not infringing, but basing your work on other ports does not necessarily isolate you from infringing the earlier work.
The second problem is that you argue that documentation of a software system cannot infringe on the copyright of that software system itself. However, copyright doesn't just protect implementation details. It protects creative expression, which may also manifest itself in the design of the software system, for example in user interfaces or the structure and organization (and naming) of APIs. If those are covered by the documentation, then reimplementing the documented design may very well infringe. Documentation is often more like a design document than a specification. And in any case, documentations, design documents, and specifications can all be creative works and therefore subject to copyright.
As a third point, you suggest that this were “clearly” non-infringing and therefore “the lawyer step can be skipped”. This misses the point of a clean-room process, which is to reduce as far as possible your risk of getting your newer work ruled as infringing. Getting your your process and various documents within that process review by legal experts is a core part of that. Clean-room reimplementation isn't a cargo-cult dance to please the copyright gods, but a legal strategy.
So I think it is difficult to implement a clean-room design on your own, and unlikely that your proposed process would stand up to scrutiny. This does not mean that you cannot reimplement the earlier work, or that you should ignore all practices of a clean room process. If you believe you can reimplement the earlier work without infringement then you can do that in good faith with or without a clean room process. But you may still value the future ability to testify before a court that you didn't look at the earlier work's source code.
