There are two great and abiding principles to keep in mind at all times here:
Those are, I hope, obviously oversimplified statements, but they are nonetheless true. Design clients are only rarely aware of them, and often need some convincing of their truth since they're quite likely to see them as an excuse to charge more money. Designers may be separated from people who have a copy (legit or not) of the Adobe suite, access to YouTube tutorials, and "an eye for that sort of thing" by their awareness of these truths. (Regrettably, it may also signal someone who's been through the whole learning gamut as a print designer, but whose transition to the web/screen has missed a few vital points. Arguably, that should only include old fogeys like me, but the evidence suggests that's not quite the case yet.)
We may prattle on about vector graphics and how we use them because they're "scalable", but that makes them sound like a miracle cure. Unfortunately, a lot of people believe in miracle cures, including some of the quacks selling them. The only thing that really scales that way is a plain monochromatic square, and even that stops working if you make it small enough that fractions of pixels become significant. What we really mean is that vectors are scalable upwards, but with some constraints. (Scaling down rarely ends well unless the design is huge compared to the coordinate system containing it.) The resolution of the output device/medium plays heavily into it; it doesn't matter at all how valid the mathematical description of the graphic is if rendering it requires seventeen thousandths of a pixel to be a certain colour. To a somewhat lesser extent, our vision itself gets involved — things can look well-proportioned at one size and just plain wrong at another (which is why "a" typeface can have a bafflingly large number of variants in the "same" weight, depending on their intended sizes).
So we build things in different sizes for different uses. Some may be "the same thing", but with some tweaking of the smaller versions to make them display properly at their intended sizes. That may involve manually lining things up with the pixel grid in order to achieve "crispness" — at the expense of optimal spacing of the elements, so a larger version of the "crisp" small version may look very awkward — and it may involve using variations on line thicknesses and different versions of fonts. Some may shuffle elements around (for vertically- or horizontally-constrained spaces) or may eliminate elements in order to make the main elements "read" properly in the space allotted for them.
Take something really simple: the Nike swoosh. It may or may not also display the Nike name, which may be below or may be to the right of the swoosh. It may or may not include whatever motto/tag line they happen to be using as well. That really is just about as simple as it gets, and yet there are several variations on the theme for different applications. The IBM logo is also very simple, and being a word mark, doesn't need a separate text element, but it stops working when the stripes get too narrow. There is a size below which it simply cannot be used anymore, and an alternate, unstriped version is used instead.
You will not find that a complex design like yours, with many tiny elements, is going to be better-behaved at small sizes. You cannot have a "one size fits all" version of that design. You may have a set of branding elements that work at various sizes and in various orientations, but unless you're going for that unadorned monochrome square look or your minimum logo display size is fairly large, it will need to be a set. Your designer should know that. (And if your designer is using a high-PPI screen, s/he should be aware that the rest of the world may be seeing something very different when the image is scaled.)
Oh, just as an aside: there's no real truth to the rumour that a favicon must be an ICO file anymore. All the
favicon.ico buys you is the convenience of not having to link the file from your page (the browser will attempt to retrieve it automatically from the site's document root). It still needs to be appropriately sized, of course, and so it won't be suitable for use on the page except as something like an alternative bullet.