Felt like a ran a marathon, totally out of breath after reading your question.
As with these types of questions, there really is no wrong or right answer as most of it is based on opinions and not facts. There are few point here that we can concretely discuss
POINT 1
Post Types need to be registered in the functions file of your theme and will not be as easily transferable when the time comes for a new theme to be activated
Totally bull unfortunately. Custom post types and custom taxonomies should never be registered in a theme, it should always go into plugin. General rule of thumb, if anything gives functionality to the site and not the theme (which is the case here), it should go into a plugin. There have been a couple of posts done on this subject, make use of the site search for extra additional info. In short, custom post types and custom taxonomies should always be available even after a theme switch if it was correctly registered from a plugin
POINT 2
Avoid custom Post Types and embrace Post Formats! Post formats are supported by WordPress core, and are already activated in the Starter Theme
Both custom post types and post formats are supported by core, and in both cases they need to be registered/added before they can be used. So this point is totally overboard and should not even be deabateble. Yes, post formats are already part of the Starter Theme, but what about theme X when you switch to theme X.
POINT 3
The custom-post-types as is – have no place in any ‘feed’ outside of this site.
True and false. This is one of the reasons that I prefer custom post types, but let we not discuss opinion. By default, custom post types are excluded from the main query except on taxonomy and post type archive pages. This gives you much more control when and where and how to use custom post types. Adding custom post types to feeds, homepages, archive pages etc is as easy as adding a simple pre_get_posts action with the desired conditions, this can also be done in the same plugin as the one ussed to register your post type
Apart from that, you do have a lot of extra additional featured you can use to manipulate your post type and how it will be used in your site by just adjusting the values to the parameters in register_post_type() when you register the post type
POINT 4
I’m wondering if I should have just included 12 scripts in the head and written the css without a preprocessor?
Never ever do that. Always use the wp_register_scripts hook to add scipts and styles to the header and footer where necessary, never hardcode these directly in the head (or footer). I’m also never a big fan of manipulating impotant functionalities with client side languages and platforms. The issue is, anything that relies on client based functions can be manipulated by the end user. Cross browser compatibility is always an issue as well. Only use JS and CSS to manipulate the face value of a site (look and feel), never let it control how a site function. Use server side languages like PHP to control that.
POINT 5
Is there really any chance of Custom Post Types going away?
There is a definite 0% percent chance that custom post types and/or post formats will ever be removed from core. Just as an extra point, register_post_type() is used to register the default post types post and page and register_taxonomy() is used to register the default taxonomies category, post_tag, post_format and link_category.
It is very very rare that anything gets removed from core, depreciation happen regularly, but removal almost never. Take for instance the still wisely used parameters caller_get_posts and showposts. These should not be used anymore as of version 3.0, but people still use it. (turn debugging on and you will gt a clear notice on this). Imagine the core developers just removing this from core.
WordPress core is quite focused on backward compatibility (specially if a feature gets a huge upgrade and changes dramatically or a feature gets depreciated) which is quite a big advantage for non developers. As a developer, notices get added to depreciated functions/arguments/etc, that is why it is always advicable to enable debugging when developing.
To get back to the original point, you do not ever need to worry that custom post types or post formats will ever be removed from core
POINT 6
I thought that the post formats were just a bonus for microblogging – and that most people were actually upset they made it into core.
In short, post formats are just a bonus, a nice-to-have. This point can be debated over and over again, also the fact how useful it really is. It really comes down to peronal preference here whether it is useful to your project or not. I’m personally not a very big fan of post formats. I still prefer a custom post type or a custom taxonomy, depending on the project requirements, above post formats. One do have much more control with custom post types and custom taxonomies than with post formats.
One big issue with post formats are the fact standard is not a post format. It is simply some crappy fallback for posts that does not have a post format assigned. Altering any given loop is messy if you need to remove or only query posts without a post format.
POINT 7
Post formats are for styling the post in certain scenarios and for micro-blogging when you want different post categorizations in a feed.
Correct is most of what has been said. Post format does not necessarily needs to be resticted to micro blogging. You can use post formats or very large projects as well depending on the exact needs of the project. But again, how you use it exactly depends on your project and personal preference
Custom post types are for groups of data that are not posts.
Not true. Yes, they are groups of data in a sense as custom post types are used to do jus9t that, but it is incorrect to say that they are not posts. Pages are posts too, so are normal posts and any custom post type post. They are all treated exactly the same, the only real difference is hierarchy. Non hierarchical post type posts (like the build in post type post) cannot have child posts while hierarchical post types (like the build in post type page) can have child posts
CONCLUSION
Custom post types (and for that matter custom taxonomies) and post formats are here to stay. Whether which to use depends on the project at hand and what you are comfortable with. This requires careful planning beforehand. It is also very important to know how and where you should register/add functionlities to keep compatibility and useability when themes changes etc
What I have given is just a basic guideline and should be treated as such. I cannot go into much more detail as this will require a book. There are really a lot of info on-site and off-site that you should check out.
Good luck on your project