[SalesForce] js remoting result returning selectOption

There are a couple of things.

1. In Apex, init() methods are not called by default. Any code you want to run during the instantiation of an Object must go in the constructor, see Using Constructors. Since JavaScript Remoting requires your methods to be Static, setting Instance Variables will not do you any good.
2. Your static method, "findAccounts" is trying to reference an instance variable, "accounts". I got a compile error when initially trying to save your class. If you want to reference the "accounts" variable from within another static method, make sure to define this as a static list.
3. Since init() is never getting called, the list of accounts will be null. If you call this init() method within the findAccounts method, then the data will be populated. Note, that you must change init() to be a static method then, as well. As referenced above, it's generally not a best practice to query all objects into memory, as you will soon hit governor limits for the total number of records retrieved by SOQL queries of 50k query rows.

If you put all that together, this should get you at least a working example.

global class MyClass
{
    public static List <Account> accounts = new List <Account>();

    public static void init()
    {
        accounts = [SELECT Id, Name FROM Account]; 
    }

    @RemoteAction
    global static Account findAccount(String accountName)
    {
        init();
        for(Account acc : accounts)
        {
             if(acc.Name == accountName)
                 return acc;
        }

        return new Account();
    }
}

Note, that this will infact requery the database everytime findAccounts is called. A design pattern I like to use, and have seen a lot looks something like the following:

public static List <Account> accounts;
public static void setAccounts()
{
    if (accounts == null){
        accounts = new List<Account>();
        accounts = [SELECT Id, Name FROM Account]; 
    }
}

This will ensure that the query is only run once within the lifespan of the request.

You also may want to utilize a Map<String, Account> accountNameToAccountMap see Apex Maps, so that you can avoid iterating through the list every single time. But, I'll leave that as an exercise.

JavaScript Remoting does not instantiate the controller or load the view state. For this reason, the methods are declared as static, because there is no instance associated with these calls. There is a buffering mechanism that causes calls that are called close together to be buffered together and submitted at once; this is a default behavior that can be modified per the JavaScript Remoting for Apex Controllers page. Disabling buffering may increase performance, although surely not as much as 2000 ms worth of delay that you're observing. My typical response time when using remoting with buffering is around 19 ms in demo classes I've written.

The server may choose to delay these requests until resources are available, just like any other request. They are not given any special priority queue, nor are they processed any differently than a normal request. They are generally faster, though, because they do not carry their view state with them, which tends to make them faster and more responsive. However, like all software systems, there can sometimes be unforeseen contention. Submitting a case with support may be able to help isolate this problem.

Classes are, as in Java, compiled to bytecode when they are successfully deployed. This means that your code should load in linear time for any given execution cycle. The size of the class and all the classes upon which it depends can play a factor. More importantly, the first run after a class changes may be delayed if there are inter-class relationships that haven't been compiled (e.g. a change to a utility class will cause all classes that use that utility class to have to re-compile on next execution). This delay is usually minor, and should only occur once per code change.

The system also depends on a cache, so loading a controller for the first time in a while (however long the cache keeps recently used bytecode) may result in a loading penalty, but again this is usually far less than your observation of 1800 ms. Generally this delay is less than 100 ms on a busy day, and I can't think of any documented reason why it would take as long as you've observed unless there's some other issue going on, usually internal in nature.

It might be worth the effort to submit a case to Developer Support and see if they can help isolate the issue. Occasionally, there are definitely hiccups in the system, but the engineers usually keep tabs on this and submit hotfixes for situations like this. You might try reducing the complexity of your code and/or splitting your remote functions across multiple classes (this is a great use case for extensions).