It was required at Sun, in Solaris engineering. Merge commits were absolutely verboten (which prohibition was enforced by tooling) -- therefore pushes had to be linear. Commit commentary had a very specific required format.

Clean, linear history has never been required anywhere else I've worked, but I've done it ever since Sun taught me to. Just because it's not required doesn't mean it's not a good idea, and it can't be forbidden ("what happens on my dev instances, stays in my dev instances", and the only thing seen in the end is what I choose to publish, and it's going to be clean and linear).

Large projects at Sun used a rebase-heavy / rebase-only workflow like so:

                +-----------------+
                | Upstream "gate" |<------+
                +-----------------+        \
                  /     \                   \
                 /       \                   \
                v         v                   \
    +--------------+    +--------------+     +--------------+
    | Project gate |    | Project gate |     | Project gate |
    | (re)based on |    | (re)based on | ... | (re)based on |
    | build N of   |    | build N+1 of |     | build N+M of |
    | upstream     |    | upstream     |     | upstream     |
    +--------------+    +--------------+     +--------------+
            ^             ^
            |            /
            |           /       ...
            v          v
      +-----------------+
      |   dev clones    |
      |                 |--+
      | periodically    |  |
      | rebased --onto  |  |--+
      | next rebasing   |  |  |
      | of project gate |  |  |
      +-----------------+  |  |
        | ...              |  |
        +------------------+  |
           | ...              |
           +------------------+

In large projects individuals tracked a project fork of the upstream, which forks were periodically rebased onto the latest "build" of the real upstream, and the individuals' forks of the project "gates" were rebased onto the latest project fork as needed. At the end, when all the i's were dotted and t's crossed, the tech lead would push the project gate's linear history additions to the upstream.

We did this with early 90s tech known as Teamware, with lots of scripting on top. We later did it with Mercurial (again, with lots of scripting on top). Mercurial was a mistake. Git is much, much easier to use this way than any other VCS I've ever worked with, which for me includes: CVS, Clearcase, PRCS, Subversion, Mercurial, Git.