Q:

How does SE remember my preferences without a POST but just a GET? 

Look at this url:
http://stackoverflow.com/questions?sort=newest

This is the default url when browsing questions.  It's normal.  There are also other optional parameters:
pagesize - int, [1..50] - the number of records returned
page - the offset

Now.  When you set the pagesize, for example to 13, such an url will be generated:
http://stackoverflow.com/questions?pagesize=13&sort=newest

But, when you change the page to a different one (the default is 1), you will get this:
http://stackoverflow.com/questions?page=2&sort=newest

Although the page is different now, the server somehow remembers that the user wants to see 13 records at a time.  Does this mean that it is not a pure GET method?  Is there some body beneath indicating the usage of a POST? 
I assume that Stack Overflow is authoritative in terms of the design, that is why I would learn why such a design. 

A:

You are right that it's not a pure GET request, because the site is not stateless.  There are a lot of things going on, and a pure REST interface just isn't useful for an advanced web site.  If every state would be sent back and forth in the URL, it would get very complicated and prone to errors. 
A web page is not just a single resource.  It usually contains a single resource as the main feature, but there are often other resources included in the page, for exampe lists of hot posts and related posts.  There can even be list of posts from other sites in the network, so those are not even resources in the current site. 
The site will remember some settings, like page size, but it will also remember a lot of other state.  For example, if you start writing an answer, it will remember what you write even if you don't post it.  If you close the question without posting, and then reopen it you still have your text that you wrote. 

A:

It is most likely that they are using a session variable to store the value of pagesize so that if it is not present in the GET params it will use the last known value in the query.  
This is a pretty standard operating procedure especially in pagination requests.  This is also how the system would know which page of your search results to return to if you clicked on a particular link to an article or product, etc. 
In Lasso this code would look something like this:
//start session and add spaces for variables
session_start($session_name)
session_addvar($session_name, 'sv_sort')
session_addvar($session_name, 'sv_page')
session_addvar($session_name, 'sv_pagesize')

//initialise session vars if they don't exist
not var_defined('sv_sort') ?  var(sv_sort = 'newest')
not var_defined('sv_page') ?  var(sv_page = 1)
not var_defined('sv_pagesize') ?  var(sv_pagesize = 10)

//test for request params to update session vars
web_request->param('sort')->asString->size ?  $sv_sort = web_request->param('sort')->asString
web_request->param('page')->asString->size ?  $sv_page = integer(web_request->param('page'))
web_request->param('pagesize')->asString->size ?  $sv_pagesize = integer(web_request->param('pagesize'))

//perform search function with the session vars
local(questions = so_questions->search($sv_sort, $sv_page, $sv_pagesize)

// output results
with q in #questions do => {^
    <output individual question html>
^}

Now when I go to the /questions page, the "missing" variables are inserted.  Also this means that when I return to /questions after reading one in detail I will return to the page I left from without the detail page needing to know anything about how I got there. 
Here, of course I am assuming a type (class) called so_questions with a public method search(sort::string, page::integer, pagesize::integer) that will return an array of html blocks suitable for output. 
Naturally this is a very stripped down example to give you the idea of how search result pages typically utilise session variables to "remember" user input. 

A:

It appears setting the page size is considered a "preference" and is remembered across sessions.   I can pass 13 as a page size, and then subsequently any page I visit on meta.stackoverflow.com with a list of questions will have 13.   I can even login via a incognito session and once logged in it will display 13 items.   So it's clearly saving that somewhere with my account. 
It is pretty common technique to consider certain choices as a long term preference.   Where and when you do this depends alot on considering the user experience. 
"Does this mean that it is not a pure GET method?  Is there some body beneath indicating the usage of a POST?" 
As far as I can tell, no, there is no header that is passing additional criteria, and nothing in a cookie holding those values, since those do not carry across to incognito.   From my tests it's clearly being associated with the user account. 
"why I would learn why such a design." 
As mentioned, it's about improving user experience.   Allowing the site to remember choices that the user is likely to prefer across the entire site.   If I got to a shopping site I often choose to see 50 items at a time, and it would be really nice if the site remembered that.   SO has chosen to make that something that is remembered across site visits.