On point four, a lot of companies aspire to having great test suites, which these days for user-facing apps often means aggressive unit and API testing on the backend, and using browser tests for end-to-end or integration tests. We're seeing companies moving away from running comprehensive functional tests in the browser because they take so long to run, and tend to be very brittle.
When it comes to writing browser tests, Selenium is still the most common tool for browser automation, but especially with the advent of Chrome Headless, there's a whole slew of new tools popping up (and there are lots of commercial tools like SmartBear's TestComplete or Telerik TestStudio). Selenium is not very popular, because it can be a pain to write the tests, and they tend to rely heavily (although it depends on how they're written) on addressing elements with XPATHs or CSS selectors, which are very brittle - especially in large teams or where the front-end is changing a lot.
It's also hard to get devs to write Selenium tests. It's tedious work, and they often need constant maintenance, so enterprise usually have dedicated test automation engineers, who are hard to find and tend to move on to better roles as soon as they can.