I have a question regarding the design of these protocols. Why do we use boundary to separate parts of the multipart message instead of introducing a content-length for each part? Using length the parsing would easier. Do I miss some principal reason for using boundaries and not length parameter? Thanks!
Using length the parsing would [be] easier
This is where you are wrong. The authors of multipart MIME had cases in mind where you could not determine beforehand the length of a message part. Think of content encodings that alter message lengths such as base64, UUencode and others. There's also compression, encryption and whatnot. Also: Content-Length is an entity header. This means if you reach it, you've already begun to parse a message part. It comes with literally no advantage over a boundary marker.
If you study older protocols, you will often encounter some marker (usually \0) to indicate the end of a message. Sending the byte count of a message is another solution, but you won't find it a lot in places where message content has to be converted on-the-fly or is to be streamed in some fashion.
Bottom line: The multipart boundary allows some interesting applications with message contents of unpredictable size. HTTP server pushing is a notable example.