Apply suggestions from code review

from @metalmatze

Co-authored-by: Matthias Loibl <mail@matthiasloibl.com>

docs/components/receive.md

@@ -8,11 +8,11 @@ menu: components
 
 The `thanos receive` command implements the [Prometheus Remote Write API](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write). It builds on top of existing Prometheus servers and retains their usefulness while extending their functionality with long-term-storage, horizontal scalability, and downsampling. The [Thanos Sidecar](./sidecar.md) is not sufficient for this, as the system would always lag the block length behind (typically 2 hours), which would prevent the most common query pattern of Prometheus: real-time queries of very recent data.
 
-This component is only recommended for uses for whom pushing is the only viable solution, for example, analytics use cases or cases where the data ingestion must be client-initiated, such as software as a service type environments.
+We recommend this component to users who can only push into a Thanos due to air-gapped environments. Examples are: analytic use cases or cases where the data ingestion must be client-initiated, such as software as a service type environments.
 
-This component is not recommended in order to achieve a global view of data of a single-tenant, for those cases the sidecar based approach with layered Thanos Queriers is recommended. Multi-tenancy may also be achievable if ingestion is not user-controlled, as then enforcing of labels, for example using the [prom-label-proxy](https://github.com/openshift/prom-label-proxy) (please thoroughly understand the mechanism if intending to employ this mechanism, as the wrong configuration could leak data).
+We don't recommend the Thanos Receiver in order to achieve a global view of data of a single-tenant. For such use cases, the sidecar based approach with layered Thanos Queriers is recommended. Multi-tenancy may also be achievable if ingestion is not user-controlled, as then enforcing of labels, for example using the [prom-label-proxy](https://github.com/openshift/prom-label-proxy) (please thoroughly understand the mechanism if intending to employ this mechanism, as the wrong configuration could leak data).
 
-Also, users are asked to note the [various pros and cons of pushing metrics](https://docs.google.com/document/d/1H47v7WfyKkSLMrR8_iku6u9VB73WrVzBHb2SB6dL9_g/edit#heading=h.2v27snv0lsur).
+Additionally, we would like to ask users to note the [various pros and cons of pushing metrics](https://docs.google.com/document/d/1H47v7WfyKkSLMrR8_iku6u9VB73WrVzBHb2SB6dL9_g/edit#heading=h.2v27snv0lsur).
 
 For more information please check out [initial design proposal](../proposals/201812_thanos-remote-receive.md).
 For further information on tuning Prometheus Remote Write [see remote write tuning document](https://prometheus.io/docs/practices/remote_write/).