Ready:
As I wrote in T148805, I oppose adding and exposing a global "ready" task status visible to everybody, as long as there are no well-defined use cases in place for more statuses and which specific problem to solve (or which specific data to measure).
We already face situations when nobody resets or corrects the "stalled" status back to "open", and I expect similar problems.
Furthermore, I expect a lot of task authors to ask what info is missing in an "open" task and what makes a task not "ready" yet. It is similar to the rather useless "UNCONFIRMED" vs "NEW" statuses that Bugzilla had once upon a time (and "ASSIGNED" status vs an assignee field).

Paused:
I'd be more open to adding a "paused" status after clearer use case distinction, and as "stalled" currently already has several semantic meanings which makes T252522: (Semi)automatically close Phabricator tickets with status "stalled" after a while rather hard to implement:
Task is unactionable due to upstream work required or depending on upstream work (should have Upstream project tag);
Parent task is unactionable due to work required on a subtask (should have subtask defined),
Task is unactionable due to missing information from a task author.

Ultimately I don't think adding statuses is the right solution, but neither is adding more tag projects.

A better solution would be labels: T261498: Implement "Labels" for workboard cards

@Aklapper: I'm not sure I understand what the problem would be if someone sets tasks to ready inappropriately? It would be treated the same as "open" everywhere and the only time it would matter is on workboards which specifically are set up to use the status via a workboard column trigger.

In T261493#6419124, @mmodell wrote:

Ultimately I don't think adding statuses is the right solution, but neither is adding more tag projects.

As long as nobody explains the problem to solve, neither I nor anyone else can decide what the "right solution" is.

I know however that I don't have to see a list of all existing project tags all of the time, while I pretty often do see a list of all existing task statuses in a dropdown.

The problem to solve is outlined in T148805, essentially to track when work starts on a task, so that we can calculate metrics for a team / workboard.

I understand that, however T148805 does not mention statuses. :) I'll comment over there.

In T261493#6419227, @Aklapper wrote:

I understand that, however T148805 does not mention statuses. :) I'll comment over there.

I mention status in the comments as one of the possible implementations.

Right. And I mentioned that I think it's by far the worst implementation, so I'm confused why this task named "Introduce new task statuses in Phabricator" was created, I guess. :)

I'd really like to see this task declined.

Honestly I think it's the best option out of all available. It's the most semantically correct and it's by far the least amount of code / work to implement which also has long term maintenance advantages.

@mmodell: I simply cannot say what's the best option as long as nobody has provided clear, specific, exact, non-abstract cases for named specific teams of some organization explaining which specific activity they would like to measure and how that activity is defined.

Until that happens, I do not see a reason for complicating things and creating maintenance costs by creating new statuses or developing labels:

We have assignee fields ("none" or an individual) so people can express that they work on a task.
We have workboard columns ("in progress", etc) so people can move tasks around to express that a task is in some state or that something happened.
We have task statuses (e.g. "resolved", "stalled") to express that a task has been done, or that it cannot be worked on.