Using HTTPS on your login and account management servers but not on other pages of your site that need access to the login (like WSJ's article pages) can leave you vulnerable to session hijacking attacks (like those demonstrated by Firesheep[1] a few years ago against Facebook and Twitter). If you want to be secure, resources that require authentication should always be accessed over SSL, and your session cookies for logged-in sessions should be set as secure (so the browser won't send them over plain HTTP).
Session hijacking only works on webpages with sessions. Most of these urls are static informational pages without sessions, from the several I looked at.
The WSJ specifically requires login to view articles (because they require an active subscription to read anything on their site). Most of the other newspaper sites (at least; not going to go and pick through the whole list) are the same, with different thresholds for when login is required.
I'm not sure what happens on the site after login on WSJ, if they are doing it semi-correctly then it should be a secure page after login. If that's not the case, then yea they should improve this. Not picking through them individually, there are a number of pages outside the newspaper category that are strictly informational without even login forms.
[1] http://en.wikipedia.org/wiki/Firesheep