The main reason to write a tree-walking interpreter is that it's easier. If you compile to bytecode and then interpret the bytecode, you are either writing a compiler to an existing bytecode language (in which case your language may have to inherit some of the bytecode language's semantics), or you are writing a compiler and an interpreter and designing a bytecode language in addition to your actual language. Compilers are generally harder to write than interpreters, and some language constructs (e.g. pattern-matching in functional languages) are not straightforward to compile to bytecode.
The main reason to compile to a bytecode language is performance. A bytecode interpreter is typically implemented as a tight loop with a switch on the opcode, compared to a tree-walking interpreter which has the overhead of pointer indirection whenever accessing child nodes in the abstract syntax tree (AST), and might dynamically dispatch on the type of AST node. The bytecode itself also typically takes up less memory than an AST, so there are fewer cache misses when interpreting it. And some optimisations, particularly peephole optimisations, can be easily performed on bytecode programs.
For most general-purpose languages intended for a wide audience, the performance consideration will win out; the more users and the more computationally intensive code written in your language, the sooner the effort of a bytecode-based implementation will pay off. On the other hand, for scripting languages designed for programs where most statements will be executed either once or not at all, the performance cost of a tree-walking interpreter will be less than the one-time cost of compiling to bytecode anyway.