add discourse link + simplify language (#4675)

after discussion with @saraleon1 -- this pr adds a discourse link to
incremental strategies discussion for large datasets and simplifies the
'when should i use an incremental model' paragraph/section. the
discourse link has been share with users a few times and Sara suggested
it'd be helpful to have this on the docs to help users.

### Current content section
![Screenshot 2023-12-19 at 13 06
23](https://github.com/dbt-labs/docs.getdbt.com/assets/89008547/fc3f9b52-3e19-4ee3-bac9-e16212118dbf)

### new proposed content + link
- [Discourse
article]((https://discourse.getdbt.com/t/on-the-limits-of-incrementality/303))

- In addition to these considerations for incremental models, it's
important to understand their limits and challenges, particularly with
large datasets. For more insights into efficient strategies, performance
considerations, and the handling of late-arriving data in incremental
models, refer to the [On the Limits of
Incrementality](https://discourse.getdbt.com/t/on-the-limits-of-incrementality/303)
discourse discussion.

website/docs/docs/build/incremental-models.md

@@ -154,17 +154,21 @@ For detailed usage instructions, check out the [dbt run](/reference/commands/run
 
 # Understanding incremental models
 ## When should I use an incremental model?
-It's often desirable to build models as tables in your data warehouse since downstream queries are more performant. While the `table` materialization also creates your models as tables, it rebuilds the table on each dbt run. These runs can become problematic in that they use a lot of compute when either:
-* source data tables have millions, or even billions, of rows.
-* the transformations on the source data are computationally expensive (that is, take a long time to execute), for example, complex Regex functions, or UDFs are being used to transform data.
 
-Like many things in programming, incremental models are a trade-off between complexity and performance. While they are not as straightforward as the `view` and `table` materializations, they can lead to significantly better performance of your dbt runs.
+Building models as tables in your data warehouse is often preferred for better query performance. However, using `table` materialization can be computationally intensive, especially when:
+
+- Source data has millions or billions of rows.
+- Data transformations on the source data are computationally expensive (take a long time to execute) and complex, like using Regex or UDFs.
+
+Incremental models offer a balance between complexity and improved performance compared to `view` and `table` materializations and offer better performance of your dbt runs. 
+
+In addition to these considerations for incremental models, it's important to understand their limitations and challenges, particularly with large datasets. For more insights into efficient strategies, performance considerations, and the handling of late-arriving data in incremental models, refer to the [On the Limits of Incrementality](https://discourse.getdbt.com/t/on-the-limits-of-incrementality/303) discourse discussion. 
 
 ## Understanding the is_incremental() macro
 The `is_incremental()` macro will return `True` if _all_ of the following conditions are met:
 * the destination table already exists in the database
 * dbt is _not_ running in full-refresh mode
-* the running model is configured with `materialized='incremental'`
+* The running model is configured with `materialized='incremental'`
 
 Note that the SQL in your model needs to be valid whether `is_incremental()` evaluates to `True` or `False`.