Create or decide on internal data formats for your engine first; you can use custom formats or handle standard ones, however you prefer. Then use this code will eat any format as an intermediate point in your content pipeline to eat your artist's output and un-eat whatever internal formats you decided to use.
When I suggest assimp I'm really just suggesting that you have a pipeline that has an intermediate step so you can be flexible. Source -> Intermediate Conversion -> Runtime. Not only can you target different runtime environments more easily, but you can change sources if something really bad happens.
The main point here is that your engine only supports one format, ever, the tools of the content pipeline are responsible for handling multiple incoming formats. This makes your engine easier to maintain and arguably more stable and less prone to bugs.
Next, stop worrying about vertex size. You're putting the "OMG I'm out of memory" cart waaay before the horse on this. Unless you've already built an engine or three before and know what limits you want to hit, but then you'd already know the answer to vertex size =)
The unspoken secondary point here is KISS Don't go adding in features before they are needed, not only will you waste time on many features that never get used but you'll annoy the pig. For example, don't worry about vertex colors until some artist has a good case for why they need them.
3D modelers don't abstract anything away, you will learn to hate their idiosyncrasies but assimp will help hide that.
One very bad point about letting artists use a variety of different modelers... they cannot exchange work without converting, and there you get the idiosyncrasies again. In terms of an ongoing production it's more sane to standardize.