README.md: Undeprecate tar_scm

obscpio breaks ability to build packages with rpmbuild for no benefit.

Until that's fixed obscpio should not be used, and hence tar_scm should
not be deprecated.

Also drop the note about being able to build the obscpio based packages
checked out from OBS. Any package can be built locally with osc build
but packages *not* based on obscpio can be additionally built with
rpmbuild.

Signed-off-by: Michal Suchanek <msuchanek@suse.de>

README.md

@@ -11,7 +11,7 @@ https://github.com/openSUSE/obs-service-tar_scm.
 
 ## Services
 
-### tar_scm *(deprecated)*
+### tar_scm
 
 `tar_scm` is the legacy source service used to create a source tarball
 from one of the supported SCM (source code management) tools: `git`,
@@ -33,7 +33,10 @@ tarball to be downloaded.
 e.g. within the [GIT integration](https://en.opensuse.org/openSUSE:Build_Service_Concept_SourceService#Example_2:_GIT_integration)
 workflow.
 
-**`tar_scm` is deprecated in favour of `obs_scm`.**
+It saves space on the server to not compress the generated tarballs. OBS can
+use delta compression on uncompressed archives. src.rpm files are compressed by
+rpm, and compressing once gives better results than compressing already
+compressed data.
 
 ### obs_scm
 
@@ -42,17 +45,9 @@ generating tarballs, it instead uses the new `obscpio` archive format
 (see below) as an intermediate space-efficient format in which to
 store the sources.
 
-**It is recommended to use `obs_scm` in favour to `tar_scm`**, because
-it provides the following advantages:
-
-1. When you `osc checkout`, you'll also get a local checkout directory
-   within the project directory, inside which you can develop as usual
-   and test your changes with local builds, even without having to
-   commit or push your changes anywhere.
-
-2. It helps to save a *lot* of disk space on the server side,
-   especially when used in continuous integration (e.g. nightly builds
-   and builds of pull requests).
+`obscpio` is not compressed which helps to save a *lot* of disk space on the
+server side, especially when used in continuous integration (e.g. nightly
+builds and builds of pull requests).
 
 The usual source tarballs can be regenerated from this at build-time
 using the `tar` and `recompress` source services, so no changes to