What objective factors indicate it's time to implement SQL Server replication?
Replication should be considered during the design phase of the application.  If you have a geographically distributed workforce/userbase, having regional databases and central databases may make sense.  Disconnected databases on laptops can "synchronize" when they finally reconnect with the network (think sales staff on the road).

As for reporting purposes, replication is NOT the answer.  Most of the performance problems in a reporting environment stem from the fact that the reports are being written against a system that is configured for online transaction processing (OLTP).

Replication for reporting purposes is simply moving your OLTP data to another server, but keeping the same report-unfriendly structure.  In essence, you are throwing more hardware at the problem and increasing your maintenance costs, but for marginal gains.

What you should be looking at is how to get the specific data that your reports need, and transform them into a more useful format.  Create a feed that grabs new transactions from your production database and stores it in a reporting database, preferably on a separate server.  Every time the feed runs, it should grab all the data that is newer than the last time it ran, transform that data, and store it.  The reports that you currently are running will give you a good idea of the types of transformations required.

By following this approach, you are going to reap huge performance benefits.