Thanks to everybody for interest!
It's a hack perfect fine for an addon used on a single site by the coder itself, but not for a standard addon where I expect the addon to use the infrastructure Xenforo is providing (and for a reason). This will hurt them in the long term.
Probably you understood me wrong. Addon will use XenForo infrastructure as much as possible since its articles are extended threads. It allows to use reports, moderation, and other addons dealing with threads (bookmarks, etc..).
Are you planing on writing a blog import script from
IP.Blog? There are quite many forum owners who migrated from IP.Board to xenforo and I am sure there may be some who also need to convert their blog.
It will appear some time. Not a hard thing but requires some time.
This will also impact designers who are wanting to do more customization on a per page basis. I just had to deal with a similar issue with XenPorta, and it was way more frustrating than if it had been done with custom content and node types (Which are just more logical).
It just seems a bit lazy to not use custom content types, when the work pays off in the extensibility you gain.
That's why TMS was created. Every customization can be added with it. Making custom content for blogs would be more logical if blogs were something completely different from forums. For example, category and forum have completely different logic that's why they are different node types. But as for blogs and threads, technically they are very-very similar.
It is not laziness, it is DRY (Dont Repeat Yourself). Moreover, the first coded version of blogs had own content types, own controllers, handlers, etc. When I finished it I looked at the code and understood that I've copied so much XF code. It was really too much and if I use this approach for diaries, events, gallery, wiki I would create a monster having more code than the core. Then, I decided to use extension approach and I loved it. Lots of things out of the box and it has potential to turn XF into a social network.