Please let's not start religious wars between "source" and "theme", I had my fair amount with Ant. 
Let's have a quick look at the "source" file of the mod (at least a version without useless things that I forgot to remove ):
<?php
function tabular_categories()
{
loadTemplate('TabularCategories');
Template_Layers::getInstance()->addEnd('tabular_categories');
loadCSSFile('TabularCategories.css');
}
So it simply:
load the template
inject the layer
* load the css file (why here? Because the "source" takes care to aggregate and minify it if needed)
This is exactly what the source should do, nothing more, nothing less. It instruct the template what to to.
And is no different from any other Elk file.
It doesn't do any check because the mod is simple and want to be just like that without multiple checks on admin and/or use settings (let's remember this is just a demo to show how to use a new function, not a fully fledged mod with options all over the place).
Then the template file:
<?php
function template_tabular_categories_above()
{
global $context, $scripturl;
$current_cat = current($context['categories']);
addInlineJavascript('
$(document).ready(function () {
var current_cat = ' . $current_cat['id'] . ';
if (window.location.hash)
current_cat = window.location.hash.substring(2);
$("#boardindex_table .header").hide();
$("#boardindex_table .divider").hide();
$("#boardindex_table .content").hide();
$("#category_" + current_cat + "_boards").fadeIn();
$("#tabcat_" + current_cat + "").addClass("active");
$("#tabular_cats li").click(function () {
$("#tabular_cats li").removeClass("active");
var id_cat = $(this).attr("id").split("_")[1];
$("#boardindex_table .content").hide();
$("#category_" + id_cat + "_boards").fadeIn();
$(this).addClass("active");
return false;
});
});', true);
echo '
<div id="tabular_cats" class="cat_bar">
<h3 class="catbg">
<ul>';
foreach ($context['categories'] as $category)
echo '
<li id="tabcat_', $category['id'], '"><a href="', $scripturl, '#c', $category['id'], '">', $category['name'], '</a></li>';
echo '
</ul>
</h3>
</div>';
}
It outputs the markup and the javascript needed. Nothing more, nothing less.
During a first approximation I put the javascript code in the subs file, but then I realised different themes may use different ids or classes, so I decided to move it to the theme and still take advantage of the addInlineJavascript function (that if needed will aggregate and minify the code if I remember correctly, but that anyway is always cleaner to use because with the second parameter set to "true" the code will be added at the end of the page all in one big chunk).
No, it doesn't defeat at all the purpose of having a theme because the template can be changed for each and every theme installed and customised the way you want (including markup, javascript and css).
You perfectly know that the difference between "theme" and "source" has always been a tiny line in Elk/SMF. I'm not saying this is the perfect final solution, I'm saying this is a possible improvement in comparison with the previous situation.
Now, debate if show the board index as tabs or as a list is a matter of the "theme" or of the "source" is totally academic. We all know that if a user wants tabs, he will not care if the theme has been designed to use tabs or not, he wants them no matter what.
Obviously if we introduce the thing as a core feature most likely all the themes will support the dual option without having to argue if it is good or bad, so this argument is sort of useless, sorry.
Additionally, since the mod uses a template function to style the tabs, what you need to do, is just to add your own TabularCategories.template.php file and a dummy function inside it:
function template_tabular_categories_above()
{
// This theme is *not* designed to use tabular categories, do *not* edit this function without my (the author) written permission and the sacrifice of a virgin.
}
just to stay on the safe side, the function is not even necessary.
Obviously the "theming" is done in the theme.
And the "decision" to show something or not is done elsewhere.
If you think about it, this is not very different from what you have now, the only actual difference is that this approach is just another step to have a better separation between the "core" and the "addons" (with all the advantages this will bring, like easier upgrades, less troubles during installation of mods, mods will work out-of-the-box on themes installed after the mod has been installed and so on).
Modern, Free, Powerful