For 3rd party ads, that is sometimes correct. What blocking js does is prevent cookie stitching, ie the joining of the first party id with the 3rd party cookie id. This is necessary for external ad networks.

Twitter runs mostly their own ads afaik, so they don't face this problem.

This is why I run uBlock Origin, which blocks the ad-tracking code at the network level. Pretty much anything in a third-party iframe doesn't even get to load from the server; the browser simply doesn't make the request. Doesn't stop anything the origin runs, but most origins don't; the third party embeds are generally the biggest threat.

This is also why Twitter having problems is such a big deal; as far as I'm aware, Twitter is serving their own ad-tracking code, rather than a third-party's code. Thus, it's harder to block completely, and any vulnerabilities might (somewhat) affect even users that are running privacy extensions.

It depends on the site. For example, a Twitter timeline or Google search engine result page only needs the https request for the auction to take place, as the ads are mixed into the first-party response.

Third-party ads inserted via javascript behave as you describe.

Blocking third-party cookies (by using ublock origin or a pi-hole or firefox) helps prevent more actors from observing your online activity, but simply by being in the ad auction, third parties can get a lot of indirect information (via real-time bidding, or RTB).