Shameless self promotion: Wysihtml5 (http://vanillaforums.org/addon/wysihtml5-plugin) is a beast when it comes to Wysiwyg editing. It produces semantic markup and doesn't make use of inline styling for more advanced stuff - it uses classes and CSS instead.

That being said, Button Bar + Markdown is a great choice. Button Bar provides accessible shortcuts and Markdown is much more easily adopted by your users than simple HTML. BBCode would also be a great choice if your users are used to BBCode (incl. yourself I see).

Just please, for the sake of all that is holy: Don't use CLEditor

In the Embedded Theme {searchbox} is placed at the end of the column, the column is set to a width of 200px, the width of the searchbox is set to 200px as well, but nevertheless the searchbox exceeds the column to the right! Setting the width of the searchbox to 168px makes it fit properly, but that difference in 32px is very strange.

You should familiarize yourself with the CSS box model if you wish to understand why you're seeing what you're seeing. Never the less, the default CSS box sizing model is content-box which excludes padding and border when calculating the width of an element. You can however easily change it to also include these in its calculation:

.Whatever {
    box-sizing: border-box;
    width: 200px;
}

Beware that the box-sizing attribute will need vendor prefixing.

To answer these:

Is a template width of 960px complying to any "standard"? I have seen the use of fixed 960px many times now, and I am wondering if that really is best practice for best site view in on different screen sizes.

960px is a good size for many devices out there, desktops and tablets alike. I usually use a 1140px grid myself and then use @media queries to create adaptive layouts for smaller devices.

Is the use of "min-width" and "max-width" uncommon, or are there any compatibility issues? A fluid theme with those two restrictions would make quite some sense (I think).

Use of these two attributes aren't exactly "uncommon" but I wouldn't go as far as calling them "common" either. They're great for creating responsive layouts, but, again, I personally prefer adaptive layouts as these usually puts me in complete control over the layout. As you mention, they're very useful for responsive, fluid layouts.

Hope that makes sense!

config.php is created and initialized upon installing Vanilla - it's not present in the archive that you download.

Great post - glad you're learning new stuff about plugin development! If I may, I have a few things to add:

Paths

First off, relying on __FILE__ or any derivatives of $_SERVER variables is a bad habit. I learned this the hard way when I started working for Vanilla - things can go awry when moving code with $_SERVER variables from one environment to another.

The first, and probably foremost, reason is that not all web servers provide you with $_SERVER variables and some web servers may only provide you with some and omit others. The second reason is that $_SERVER variables are pretty oblivious to symlinks: These are automatically resolved, thus in most cases resulting in unreachable files.

Lastly, I personally "never" (exceptions occur) use any include or require statements in my code. I rely solely on autoloading and would usually write my own spl_autoload_register functions before discovering how to include stuff directly in the Garden autoloader - http://vanillaforums.org/discussion/23402/how-to-register-files-and-folders-in-the-garden-autoloader-2-1

View paths

Again, the stuff I wrote about $_SERVER vars also applies here. I'm not sure if the following is the case in 2.0, but this is how I include views in my 2.1 plugins:

$this->FetchView('fooview', 'barfolder', 'plugins/FooBar');

This would fetch the following view (plugins/FooBar and barfolder can be omitted in many cases):
plugins/FooBar/views/barfolder/fooview.ext where ext can be either tpl or php.

I think that was my 50 cents!

A very simple implementation could look like this:

$MeBox = file_get_contents(http://example.com/dashboard/module/memodule);
echo $MeBox;